Currently in Sema::ActOnEnumBody(...) when calculating NumPositiveBits we miss
the case where there is only a single enumerator with value zero and the case of
an empty enum. In both cases we end up with zero positive bits when in fact we
need one bit to store the value zero.
This PR updates the calculation to account for these cases.
Differential Revision: https://reviews.llvm.org/D130301
This compensates for 8f0c901c1a which enabled
-Wunused-command-line-argument for unimplemented -mtune= in the generic code.
Ignoring -mtune= appears to be longstanding and the error-free behavior in the
presence of -Werror is unfortunately relied on by the Linux kernel's arm and
powerpc ports. Ignore the warnings for the upcoming 15.0.0 branch and will
implement functionality to fill the test gap soon.
Link: https://github.com/ClangBuiltLinux/linux/issues/1674
Firstly, we we make an additional GNUInstallDirs-style variable. With
NixOS, for example, this is crucial as we want those to go in
`${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir
of the "regular" libdir, which is installed even when no one needs to do
any development.
Secondly, we make *Config.cmake robust to absolute package install
paths. We for NixOS will in fact be passing them absolute paths to make
the `${dev}` vs `${out}` distinction mentioned above, and the
GNUInstallDirs-style variables are suposed to support absolute paths in
general so it's good practice besides the NixOS use-case.
Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other
install dirs are.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D117973
We call tail-call-elim near the beginning of the pipeline,
but that is too early to annotate calls that get added later.
In the motivating case from issue #47852, the missing 'tail'
on memset leads to sub-optimal codegen.
I experimented with removing the early instance of
tail-call-elim instead of just adding another pass, but that
appears to be slightly worse for compile-time:
+0.15% vs. +0.08% time.
"tailcall" shows adding the pass; "tailcall2" shows moving
the pass to later, then adding the original early pass back
(so 1596886802 is functionally equivalent to 180b0439dc ):
https://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&remote=rotateright
Note that there was an effort to split the tail call functionality
into 2 passes - that could help reduce compile-time if we find
that this change costs more in compile-time than expected based
on the preliminary testing:
D60031
Differential Revision: https://reviews.llvm.org/D130374
The latter way to abbreviate is a lot more common in the LLVM codebase.
Reviewed By: sgatev, xazax.hun
Differential Revision: https://reviews.llvm.org/D130423
Fix `MapLattice` API to return `std::pair<iterator, bool>`,
allowing users to detect when an element has been inserted without
performing a redundant map lookup.
Differential Revision: https://reviews.llvm.org/D130497
and use fallback only for C.
It fixes the isssue with clang-cl:
```
#include <stdatomic.h>
#include <stdbool.h>
#ifdef __cplusplus
#include <atomic>
using namespace std;
#endif
int main() {
atomic_bool b = true;
}
```
```
$ clang-cl /TC main.cpp
# works
```
```
$ clang-cl /TP /std:c++20 main.cpp
stdatomic.h(70,6): error: conflicting types for 'atomic_thread_fence'
void atomic_thread_fence(memory_order);
^
atomic(166,24): note: previous definition is here
extern "C" inline void atomic_thread_fence(const memory_order _Order) noexcept {
...
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
```
Many errors but
`<stdatomic.h>` has many macros to built-in functions.
```
#define atomic_thread_fence(order) __c11_atomic_thread_fence(order)
```
and MSVC `<atomic>` has real functions.
and the built-in functions are redefined.
Reviewed By: #libc, aaron.ballman, Mordante
Differential Revision: https://reviews.llvm.org/D130419
This includes the revised provisions of [basic.lookup.argdep] p4
1. ADL is amended to handle p 4.3 where functions in trasitively imported modules may
become visible when they are exported in the same namespace as a visible type.
2. If a function is in a different modular TU, and has internal-linkage, we invalidate
its entry in an overload set.
[basic.lookup.argdep] p5 ex 2 now passes.
Differential Revision: https://reviews.llvm.org/D129174
Currently the C++20 concepts are only merged in `ASTReader`, i.e. when
coming from different TU. This can causes ambiguious reference errors when
trying to access the same concept that should otherwise be merged.
Please see the added test for an example.
Note that we currently use `ASTContext::isSameEntity` to check for ODR
violations. However, it will not check that concept requirements match.
The same issue holds for mering concepts from different TUs, I added a
FIXME and filed a GH issue to track this:
https://github.com/llvm/llvm-project/issues/56310
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D128921
This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.
Differential Revision: https://reviews.llvm.org/D129048
This test is currently marked as XFAIL for Windows, but running the
test with a debug build of clang-repl.exe crashes with a modal system
dialog. This switches the test to UNSUPPORTED instead. This makes the
test behavior less onerous for those of us doing Debug builds, at the
expense of a minor bit of coverage if the test were ever to start
passing unexpectedly on Windows (which seems like an unlikely event).
specialization
Previously in D120397, we've handled the linkage for function template
and its specialization. But we forgot to handle it for class templates
and their specialization. So we make it in the patch with the similar
approach.
Copying the folder keeps the original permissions by default. This
creates problems when the source folder is read-only, e.g. in a
packaging environment.
Then, the copied folder in the build directory is read-only as well.
Later on, other files are copied into that directory (in the build
tree), failing when the directory is read-only.
Fix that problem by copying the folder without keeping the original
permissions.
Follow-up to D130254.
Differential Revision: https://reviews.llvm.org/D130338
Avoid a crash if a function is imported that has auto return type that
references to a template with an expression-type of argument that
references into the function's body.
Fixes issue #56047
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D129640
Support for functions wmemcpy, wcslen, wcsnlen is added to the checker.
Documentation and tests are updated and extended with the new functions.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D130091
report an error when encountering 'while' token parsing declarator
```
clang/test/Parser/while-loop-outside-function.c:3:1: error: while loop outside of a function
while // expected-error {{while loop outside of a function}}
^
clang/test/Parser/while-loop-outside-function.c:7:1: error: while loop outside of a function
while // expected-error {{while loop outside of a function}}
^
```
Fixes: https://github.com/llvm/llvm-project/issues/34462
Differential Revision: https://reviews.llvm.org/D129573
They have been ported and tested to work on AArch64
(see D125883, D125758, and D125873).
Reviewed By: dim, MaskRay
Differential Revision: https://reviews.llvm.org/D130063
This patch connects the check for const-correctness with the new general
utility to add `const` to variables.
The code-transformation is only done, if the detected variable for const-ness
is not part of a group-declaration.
The check allows to control multiple facets of adding `const`, e.g. if pointers themself should be
marked as `const` if they are not changed.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D54943
As per P2327R1,
|=, &= and ^= are no longer deprecated in all languages mode.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130421
5ab6ee7599 assumed that if `RValue::isScalar()` returns true then `RValue::getScalarVal` will return a valid value. This is not the case when the return value is `void` and so void message returns would crash if they hit this path. This is triggered only for cases where the nil-handling path needs to do something non-trivial (destroy arguments that should be consumed by the callee).
Reviewed By: triplef
Differential Revision: https://reviews.llvm.org/D123898
llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.
Reviewed By: nhaehnle
Differential Revision: https://reviews.llvm.org/D130406
The #warning directive is standard in C++2b and C2x,
this adjusts the pedantic and extensions warning accordingly.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130415
This implements
N2836 Identifier Syntax using Unicode Standard Annex 31.
The feature was already implemented for C++,
and the semantics are the same.
Unlike C++ there was, afaict, no decision to
backport the feature in older languages mode,
so C17 and earlier are not modified and the
code point tables for these language modes are conserved.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130416
-gsplit-dwarf produces a .dwo file which will not be processed by the linker. If
.dwo files contain relocations, they will not be resolved. Therefore the
practice is that .dwo files do not contain relocations.
Address ranges and location description need to use forms/entry kinds indexing
into .debug_addr (DW_FORM_addrx/DW_RLE_startx_endx/etc), which is currently not
implemented.
There is a difficult-to-read MC error with -gsplit-dwarf with RISC-V for both -mrelax and -mno-relax.
```
% clang --target=riscv64-linux-gnu -g -gsplit-dwarf -c a.c
error: A dwo section may not contain relocations
```
We expect to fix -mno-relax soon, so report a driver error for -mrelax for now.
Link: https://github.com/llvm/llvm-project/issues/56642
Reviewed By: compnerd, kito-cheng
Differential Revision: https://reviews.llvm.org/D130190
Fixes modular build for clangPseudoGrammar from clang-tools-extra.
Starting from https://reviews.llvm.org/D126731 clangPseudoGrammar
doesn't depend on generated .inc headers but still depends on
"Basic/TokenKinds.h". It means clangPseudoGrammar depends on module
'Clang_Basic' which does depend on generated .inc headers. To avoid
these coarse dependencies and extra build steps, extract
"clang/Basic/TokenKinds.h" into a top-level module 'Clang_Basic_TokenKinds'.
rdar://97387951
Differential Revision: https://reviews.llvm.org/D130377
This commit adds a fuzzer for LLDB's expression evaluator.
The fuzzer takes a different approach than the current fuzzers
present, and uses an approach that is currently being used for
clang fuzzers.
Instead of fuzzing the evaluator with randomly mutated
characters, protobufs are used to generate a subset of C++. This
is then converted to valid C++ code and sent to the expression
evaluator. In addition, libprotobuf_mutator is used to mutate
the fuzzer's inputs from valid C++ code to valid C++ code, rather
than mutating from valid code to total nonsense.
Differential revision: https://reviews.llvm.org/D129377
Shafik Yaghmour