When applying format changes to staged files, git-clang-format
erroneously checks out all files in the index and thus may overwrite
unstaged changes.
Fixes#65643.
(cherry picked from commit 743659be87daff4cc8861c525d4a6229d787ef14)
Don't remove the outermost parentheses surrounding a return statement
expression when inside a function/lambda that has the decltype(auto)
return type.
Fixed#67892.
(cherry picked from commit 75441a684273268ce91036aa2c770e669d39f501)
On MinGW targets, the .ctors section is always used for constructors.
When using the .ctors section, the constructors need to be emitted in
reverse order to get them execute in the right order. (Constructors with
a specific priority are sorted separately by the linker later.) In LLVM,
in CodeGen/AsmPrinter/AsmPrinter.cpp, there's code that reverses them
before writing them out, executed when using the .ctors section. This
logic is done whenever TM.Options.UseInitArray is set to false. Thus,
make sure to set UseInitArray to false for this target.
This fixes https://github.com/llvm/llvm-project/issues/55938.
(cherry picked from commit a2b8c49c1839076b540c542c024fcfe2361a3e47)
Right now, `-Wformat` for a scoped enum will suggest a cast based on the
format specifier being used. This can lead to incorrect results, e.g.
attempting to format a scoped enum with `%s` would suggest casting to
`char *` instead of fixing the specifier. Change the logic to treat the
scoped enum's underlying type as the intended type to be printed, and
suggest format specifier changes and casts based on that.
(cherry picked from commit 0b07b06effe5fdf779b75bb5ac6cf15e477cb0be)
Prior to 591c4b64b3650884c2c68eb47d755ebb62981b99, the mingw specific
linker options -mthreads, -mconsole, -mwindows and -mdll would be
tolerated also at compile time, but generating a warning about being
unused.
After that commit, they were marked as target specific, which means that
it's an error if they're unused (which would consider them used for the
wrong target). These specific options are only relevant when linking,
but we want to tolerate them at compile time too, like before.
This was fixed for -mthreads in
a79995ca6004082774a87f7a58ab6be5343364b7, while the other options didn't
seem to be commonly used during compilation.
After the 17.x release, we've got more reports about this actually being
an issue, in #64464. Therefore, apply the same fix for them; marking
them as tolerated for mingw targets during compilation, even if they're
unused. Also add a testcase for -mthreads which was already handled.
Thus, this fixes#64464.
(cherry picked from commit e39de2b8862ae43459324da84279366997265078)
Adapted from the original commit; the test in the original commit
depended on f39c399d9d15efe8309d8aa3d0ecf62205e6c474. Instead of
using -###, when we're not actually using the printed output of
-###, instead use -fdriver-only.
Previously a relative path would be used as a key for cache lookup and
if the same relative path was used from another compiler invocation with
a different working directory then the first cache entry was erroneously
returned.
(cherry picked from commit 36b37c775c285bbff9b57630e7ea9d00b918cc91)
`Lexer::getLocForEndOfToken` is documented as returning an invalid
source location when the end of the token is inside a macro expansion.
We don't want that for this particular application, so just calculate
the end location directly instead.
Before this, format fix-its would omit the closing parenthesis (thus
producing invalid code) for macros, e.g.:
```
$ cat format.cpp
extern "C" int printf(const char *, ...);
enum class Foo { Bar };
#define LOG(...) printf(__VA_ARGS__)
void f(Foo foo) { LOG("%d\n", foo); }
$ clang -fsyntax-only format.cpp
format.cpp:4:29: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
4 | void f(Foo f) { LOG("%d\n", f); }
| ~~ ^
| static_cast<int>(
format.cpp:3:25: note: expanded from macro 'LOG'
3 | #define LOG(...) printf(__VA_ARGS__)
| ^~~~~~~~~~~
1 warning generated.
```
We now emit a valid fix-it:
```
$ clang -fsyntax-only format.cpp
format.cpp:4:31: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
4 | void f(Foo foo) { LOG("%d\n", foo); }
| ~~ ^~~
| static_cast<int>( )
format.cpp:3:25: note: expanded from macro 'LOG'
3 | #define LOG(...) printf(__VA_ARGS__)
| ^~~~~~~~~~~
1 warning generated.
```
Fixes https://github.com/llvm/llvm-project/issues/63462
(cherry picked from commit 61c5ad8857a71510e4393680a1e42740da4ba6fa)
An assertion issue that arose when handling union member access with
virtual base class has been addressed. As pointed out by @zygoloid,
there is no need for further derived-to-base analysis in this instance,
so we can bail out upon encountering a virtual base class. Minor
refinement on the function name as we might not be handling a union.
Reported-By: ormris
Fixes: https://github.com/llvm/llvm-project/issues/65982
(cherry picked from commit 660876a4019b81b5a7427a3dcec5ce8c39cd1ee0)
When the caret location is lower than the lowest source range, clang is
printing wrong line numbers. The first line number should consider caret
location line even when there are source ranges provided.
Current wrong line example: https://godbolt.org/z/aj4qEjzs4
(cherry picked from commit ef5217b3c0dcbb58927fe43400b6d1faa677bf98)
As reported by mgorny at https://reviews.llvm.org/D159115#4638037, the
unsigned long long cast fails on 32-bit systems at least with GCC.
It looks like a pointer provenance/aliasing issue rather than a bug in GCC.
Acked by Vassil Vassilev on the original revision.
(cherry picked from commit 3403686b72507e3fdbcd69f21fb9235ffa0ca169)
The associated commit was reverted and backported in a93ca35, so this
release note line should also be removed.
This reverts commit 061e855767dbe0821d81a8d47158f468dd00ae5f.
`clang::runWithSufficientStackSpace` requires the address of the
initial stack bottom to prevent potential stack overflows.
In addition, add a fallback to ASTFrontendAction in case any client
forgets to call it when not through CompilerInstance::ExecuteAction,
which is rare.
Fixes https://github.com/clangd/clangd/issues/1745.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D158967
(cherry picked from commit e257c0a9190637e44e292271103a13d70bec4b03)
This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```
It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```
I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.
Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.
Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.
Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159173
(cherry picked from commit e9d454d1c195958645fb0948f8b97262e7f8b33a)
clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.
The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.
Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.
An execute-only target disallows data access to code sections.
-fsanitize=function and -fsanitize=kcfi instrument indirect function
calls to load a type hash before the function label. This results in a
non-execute access to the code section and a runtime error.
To solve the issue, -fsanitize=function should not be included in any
check group (e.g. undefined) on an execute-only target. If a user passes
-fsanitize=undefined, there is no error and no warning. However, if the
user explicitly passes -fsanitize=function or -fsanitize=kcfi on an
execute-only target, an error will be emitted.
Fixes: https://github.com/llvm/llvm-project/issues/64931.
Reviewed By: MaskRay, probinson, simon_tatham
Differential Revision: https://reviews.llvm.org/D158614
A check pattern in clang/test/SemaCXX/template-64605.cpp contains template
specialization kind (the text "implicit_instantiation"). It does not need to
be checked and can be safely removed.
Presence of this text in the check pattern prevents from backporting some
commits to the release branch: https://github.com/llvm/llvm-project/issues/64605.
It has only recently been printed and the relevant commit is not present in
the release/17.x branch.
(cherry picked from commit 8859c644ede4898f90f77dcad2286de08a9ba62e)
The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.
(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)
When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.
To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.
This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).
Differential Revision: https://reviews.llvm.org/D158158
(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)
5d8aaad445
removed the warning group as the functionality is no longer a GNU
extension. However, users have asked for the warning group to be
supported so that code transitioning from Clang 16 to Clang 17 has an
easier migration path when compiling with -Werror. This patch restores
the warning group, but as an ignored warning group because the
functionality is now always considered to be a C extension rather than
a GNU extension. This allows users to do:
-Werror -pedantic -Wno-gnu-empty-intializer -Wno-c2x-extensions
to silence the diagnostics in both Clang 16 and Clang 17.
Fixes https://github.com/llvm/llvm-project/issues/64357
Differential Revision: https://reviews.llvm.org/D157503
(cherry picked from commit 151214b40d869455666ca76548a9e3ad639f79de)
From https://en.cppreference.com/w/cpp/language/decltype:
Note that if the name of an object is parenthesized, it is treated as an
ordinary lvalue expression, thus decltype(x) and decltype((x)) are often
different types.
Fixes#64786.
Differential Revision: https://reviews.llvm.org/D158155
(cherry picked from commit e3a79503a30f8c9d8fba79f3e5427bb895f320cf)
This patch fixes the reported regression caused by D146358 through adding notes about an uninitialized base class when we diagnose uninitialized constructor.
This also changes the wording from the old one in order to make it clear that the uninitialized subobject is a base class and its constructor is not called.
Wording changes:
BEFORE: `subobject of type 'Base' is not initialized`
AFTER: `constructor of base class 'Base' is not called`
Fixes https://github.com/llvm/llvm-project/issues/63496
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D153969
Original commit message:"
ORC splits into separate dylibs symbols coming from the process and symbols
materialized in the Jit. This patch adapts intent of the existing interface and
adds a regression test to make sure both Jit'd and compiled symbols can be found.
Differential revision: https://reviews.llvm.org/D159115
"
This patch disables the test statement on windows as it seems we might have a
bug in the way we model dllimports.
(cherry picked from commit 452cb7f20bc7b976eb6fec4ac9f2d902f4175c08)
Some options are only claimed in AddX86TargetArgs/etc (called by
Clang::RenderTargetOptions).
For assembler input, `Add*TargetArgs` is not called. If an option is
unclaimed, it either leads to a -Wunused-command-line-argument warning
or an error (if `TargetSpecific` is set)
```
// clang '-###' --target=x86_64 -mfpmath=sse -c a.s
clang: error: unsupported option '-mfpmath=sse' for target 'x86_64'
```
For -mfpmath=, it's actually claimed by RenderFloatingPointOptions,
which should be moved to AddARMTargetArgs/AddX86TargetArgs later
(non-AArch32-non-x86 targets give a frontend error).
This change is localized and similar to D153691, for release/17.x
backporting.
Fix https://github.com/llvm/llvm-project/issues/65023
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159010
(cherry picked from commit 081afa3d04a4bc0d43c62b5b0e5a84f86a8a70ec)
`clang` currently lacks PIE support on Solaris. This patch fixes this,
also linking with `crtbeginS.o` and `crtendS.o` for `-pie` and `-shared`.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D158206
(cherry picked from commit 62945bb811169ffac7cf22c64b6dd3a3ad8d38f0)
Close https://github.com/llvm/llvm-project/issues/56301
Close https://github.com/llvm/llvm-project/issues/64151
See the summary and the discussion of https://reviews.llvm.org/D157070
to get the full context.
As @rjmccall pointed out, the key point of the root cause is that
currently we didn't implement the semantics for '@llvm.coro.save' well
("after the await-ready returns false, the coroutine is considered to be
suspended ") well.
Since the semantics implies that we (the compiler) shouldn't write the
spills into the coroutine frame in the await_suspend. But now it is possible
due to some combinations of the optimizations so the semantics are
broken. And the inlining is the root optimization of such optimizations.
So in this patch, we tried to add the `noinline` attribute to the
await_suspend call.
Also as an optimization, we don't add the `noinline` attribute to the
await_suspend call if the awaiter is an empty class. This should be
correct since the programmers can't access the local variables in
await_suspend if the awaiter is empty. I think this is necessary for the
performance since it is pretty common.
Another potential optimization is:
call @llvm.coro.await_suspend(ptr %awaiter, ptr %handle,
ptr @awaitSuspendFn)
Then it is much easier to perform the safety analysis in the middle
end.
If it is safe to inline the call to awaitSuspend, we can replace it
in the CoroEarly pass. Otherwise we could replace it in the CoroSplit
pass.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D157833
The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.
(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)
When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.
To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.
This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).
Differential Revision: https://reviews.llvm.org/D158158
(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)
On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.
The failure without this change:
x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
// NOGATHER: "-target-feature" "+prefer-no-gather"
^
<stdin>:5:44: note: possible intended match here
clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
^
(cherry picked from commit 547ee1c81fceaabcb7064ed525f11f9e94083f56)
Close https://github.com/llvm/llvm-project/issues/59723.
The fundamental cause of the above issue is that we assumed the memory
of coroutine frame can be released by stack unwinding automatically
if the allocation of the coroutine frame is elided. But we missed one
point: the stack unwinding has different semantics with the explicit
coroutine_handle<>::destroy(). Since the latter is explicit so it shows
the intention of the user. So we can blame the user to destroy the
coroutine frame incorrectly in case of use-after-free happens. But we
can't do so with stack unwinding.
So after this patch, we won't think the exceptional terminator don't
leak the coroutine handle unconditionally. Instead, we think the
exceptional terminator will leak the coroutine handle too if the
coroutine is leaked somewhere along the search path.
Concretely for C++, we can think the exceptional terminator is not
special any more. Maybe this may cause some performance regressions.
But I've tested the motivating example (std::generator). And on the
other side, the coroutine elision is a middle end opitmization and not
a language feature. So we don't think we should blame such regressions
especially we are correcting the miscompilations.
(cherry picked from commit 7037331a2f05990cd59f35a7c0f6ce87c0f3cb5f)
This was an oversight in D146872, where function calls with tuple type
was not covered. This commit fixes this.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D157953
(cherry picked from commit 39a41c8905618fc942100630b4ea37f0cb95e786)
