We deferred the evaluation of dependent immediate invocations in https://reviews.llvm.org/D119375 until instantiation.
We should also not consider them referenced from a non-consteval context.
Fixes: https://github.com/llvm/llvm-project/issues/55601
```
template<typename T>
class Bar {
consteval static T x() { return 5; }
public:
Bar() : a(x()) {}
private:
int a;
};
Bar<int> g();
```
Is now accepted by clang. Previously it errored with: `cannot take address of consteval function 'x' outside of an immediate invocation Bar() : a(x()) {}`
Differential Revision: https://reviews.llvm.org/D132031
This reverts commit 258c3aee54.
This should fix the libc++ issue that caused the revert, by re-designing
slightly how we determined when we should evaluate the constraints.
Additionally, many of the other components to the original patch (the
NFC parts) were committed separately to shrink the size of this patch
for review.
Differential Revision: https://reviews.llvm.org/D126907
When expanding undeclared function parameters, we should initialize
the original number of expansions, if known, before trying to expand
them, otherwise a length mismatch with an outer pack might not be
diagnosed.
Fixes PR56094.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131802
DR692 handles two cases: pack expansion (for class/var template) and function parameter pack. The former needs DR1432 as a fix, and the latter needs DR1395 as a fix. However, DR1432 has not yet made a wording change. so I made a tentative fix for DR1432 with the same spirit as DR1395.
Reviewed By: aaron.ballman, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128745
Before this patch type traits are checked in Parser, so use type traits
directly did not cause assertion faults. However if type traits are initialized
from a template, we didn't perform arity checks before evaluating. This
patch moves arity checks from Parser to Sema, and performing arity
checks in Sema actions, so type traits get checked corretly.
Crash input:
```
template<class... Ts> bool b = __is_constructible(Ts...);
bool x = b<>;
```
After this patch:
```
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:5:32: error: type trait requires 1 or more arguments; have 0 arguments
template<class... Ts> bool b = __is_constructible(Ts...);
^~~~~~~~~~~~~~~~~~
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:6:10: note: in instantiation of variable template specialization 'b<>' requested here
bool x = b<>;
^
1 error generated.
```
See https://godbolt.org/z/q39W78hsK.
Fixes https://github.com/llvm/llvm-project/issues/57008
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131423
Followup patch for D128083
Previously, using a non-consteval constructor from an consteval constructor would code generates the consteval constructor.
Example
```
template <typename T>
struct S {
T i;
consteval S() = default;
};
struct Foo {
Foo() {}
};
void func() {
S<Foo> three; // incorrectly accepted by clang.
}
```
This happened because clang erroneously disregards `consteval` specifier for a `consteval explicitly defaulted special member functions in a class template` if it has dependent data members without a `consteval default constructor`.
According to
```
C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358):
If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a constexpr function or constexpr constructor, that
specialization is still a constexpr function or constexpr constructor,
even though a call to such a function cannot appear in a constant
expression.
```
Therefore the `consteval defaulted constructor of a class template` should be considered `consteval` even if the data members' default constructors are not consteval.
Keeping this constructor `consteval` allows complaining while processing the call to data member constructors.
(Same applies for other special member functions).
This works fine even when we have more than one default constructors since we process the constructors after the templates are instantiated.
This does not address initialization issues raised in
[2602](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2602) and compiler divergence seen in https://godbolt.org/z/va9EMvvMe
Fixes: https://github.com/llvm/llvm-project/issues/51593
Differential Revision: https://reviews.llvm.org/D131479
Clang currently crashes when lowering a consteval list initialization
of a temporary. This is partially working around an issue in the
template instantiation code (TreeTransform::TransformCXXTemporaryObjectExpr())
that does not yet know how to handle list initialization of temporaries
in all cases. However, it's also helping reduce fragility by ensuring
we always have a valid QualType when trying to emit a constant
expression during IR generation.
Fixes#55871
Differential Revision: https://reviews.llvm.org/D131194
For failed static assertions, try to take the expression apart and print
useful information about why it failed. In particular, look at binary
operators and print the compile-time evaluated value of the LHS/RHS.
Differential Revision: https://reviews.llvm.org/D130894
When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c07240 (and later extended in
b636875196).
When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.
The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.
The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.
This differs from GCC, which rejects PCH files if the defines differ
at all.
When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).
However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.
Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.
This fixes https://github.com/lhmouse/mcfgthread/issues/63.
Differential Revision: https://reviews.llvm.org/D126676
Implicitly converting between incompatible function pointers in C is
currently a default-on warning (it is an error in C++). However, this
is very poor security posture. A mismatch in parameters or return
types, or a mismatch in calling conventions, etc can lead to
exploitable security vulnerabilities. Rather than allow this unsafe
practice with a warning, this patch strengthens the warning to be an
error (while still allowing users the ability to disable the error or
the warning entirely to ease migration). Users should either ensure the
signatures are correctly compatible or they should use an explicit cast
if they believe that's more reasonable.
Differential Revision: https://reviews.llvm.org/D131351
A one-bit signed bit-field can only hold the values 0 and -1; this
corrects the diagnostic behavior accordingly.
Fixes#53253
Differential Revision: https://reviews.llvm.org/D131255
In D130058 we diagnose the undefined behavior of setting the value outside the
range of the enumerations values for an enum without a fixed underlying type.
Based on feedback we will provide users to the ability to downgrade this
diagnostic to a waring to allow for a transition period. We expect to turn this
diagnostic to an error in the next release.
Differential Revision: https://reviews.llvm.org/D131307
Consider:
A == 5 && A != 5
IfA is 5, the old collectConjunctionTerms() would call itself again for
the LHS (which it ignores), then the RHS (which it also ignores) and
then just return without ever adding anything to the Terms array.
Differential Revision: https://reviews.llvm.org/D131070
Close#56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for
fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions
and %B for the printf family of functions.
glibc 2.35 and latest Android bionic added %b/%B printf support. From
https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available
yet.
Like GCC, we don't test library support.
GCC 12 -Wformat -pedantic emits a warning:
> warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=]
The behavior is not ported.
Note: `freebsd_kernel_printf` uses %b differently.
Reviewed By: aaron.ballman, dim, enh
Differential Revision: https://reviews.llvm.org/D131057
This patch enhances clang's ability to check compile-time determinable
string literals as format strings, and can give FixIt hints at literals
(unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805
mentiond two compile-time string cases. And this patch partially fixes
one.
```
constexpr const char* foo() {
return "%s %d";
}
int main() {
printf(foo(), "abc", "def");
return 0;
}
```
This patch enables clang check format string for this:
```
<source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat]
printf(foo(), "abc", "def");
~~~~~ ^~~~~
<source>:2:42: note: format string is defined here
constexpr const char *foo() { return "%s %d"; }
^~
%s
1 warning generated.
```
Reviewed By: aaron.ballman
Signed-off-by: YingChi Long <me@inclyc.cn>
Differential Revision: https://reviews.llvm.org/D130906
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
We already correctly rejected:
typedef __attribute__((vector_size(16))) _BitInt(4) Ty;
but we would assert with:
typedef __attribute__((ext_vector_type(4))) _BitInt(4) Ty;
Now we issue the same error in both cases.
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
VisitCXXConstructExpr() will later do something similar, but for large
arrays, we should try to do it once an not for every element.
Fixes#56774
Differential Revision: https://reviews.llvm.org/D130791
We didn't check that a destructor's name matches the directly enclosing class if the class was dependent.
I enabled the check we already had for non-dependent types, which seems to work. Added appropriate tests.
Fixes GitHub issue #56772
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D130936
This reverts commit 0cc3c184c7.
The changes did not account for templated code where one instantiation
may trigger the diagnostic but other instantiations will not, as in:
```
template <int I, class T>
void foo(int x) {
bool b1 = (x & sizeof(T)) == 8;
bool b2 = (x & I) == 8;
bool b3 = (x & 4) == 8;
}
void run(int x) {
foo<4, int>(8);
}
```
This is a follow-up to D130058 to fix how we handle the Max value we obtain from
getValueRange(...) in IntExprEvaluator::VisitCastExpr(...) which in the case of
an enum that contains an enumerator with the max integer value will overflow by
one.
The fix is to decrement the value of Max and use slt and ult for comparison Vs
sle and ule.`
Differential Revision: https://reviews.llvm.org/D130811
C99 6.7.4p2 clarifies that a function specifier can only be used in the
declaration of a function. _Noreturn is a function specifier, so it is
a constraint violation to write it on a structure or union field, but
we missed that case.
Fixes#56800
DR2338 clarified that it was undefined behavior to set the value outside the
range of the enumerations values for an enum without a fixed underlying type.
We should diagnose this with a constant expression context.
Differential Revision: https://reviews.llvm.org/D130058
The patch mainly focuses on the lack of warnings for
-Wtautological-compare. It works fine for positive numbers but doesn't
for negative numbers. This is because the warning explicitly checks for
an IntegerLiteral AST node, but -1 is represented by a UnaryOperator
with an IntegerLiteral sub-Expr.
For the below code we have warnings:
if (0 == (5 | x)) {}
but not for
if (0 == (-5 | x)) {}
This patch changes the analysis to not look at the AST node directly to
see if it is an IntegerLiteral, but instead attempts to evaluate the
expression to see if it is an integer constant expression. This handles
unary negation signs, but also handles all the other possible operators
as well.
Fixes#42918
Differential Revision: https://reviews.llvm.org/D130510
DR2338 clarified that it was undefined behavior to set the value outside the
range of the enumerations values for an enum without a fixed underlying type.
We should diagnose this with a constant expression context.
Differential Revision: https://reviews.llvm.org/D130058
Add the support for `atomic compare` and `atomic compare capture` in the
release note of clang.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D129211
Without the "found declaration" it is later not possible to know where the operator declaration
was brought into the scope calling it.
The initial motivation for this fix came from #55095. However, this also has an influence on
`clang -ast-dump` which now prints a `UsingShadow` attribute for operators only visible through
`using` statements. Also, clangd now correctly references the `using` statement instead of the
operator directly.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D129973
Currently, the use of preferred_name would block implementing std
modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490
for example.
The problem is pretty hard and it looks like we couldn't solve it in a
short time. So we sent this patch as a workaround to avoid blocking us
to modularize STL. This is intended to be fixed properly in the future.
Reviewed By: erichkeane, aaron.ballman, tahonermann
Differential Revision: https://reviews.llvm.org/D130331
Before the patch we calculated the NRVO candidate looking at the
variable's whole enclosing scope. The research in [P2025] shows that
looking at the variable's potential scope is better and covers more
cases where NRVO would be safe and desirable.
Many thanks to @Izaron for the original implementation.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119792
Since clang15 is going to be branched in July 26, and C++ modules still
lack an update on ReleaseNotes. Although it is not complete yet, I think
it would be better to add one since we've done many works for C++20
Modules in clang15.
Differential Revision: https://reviews.llvm.org/D129138
This partially reverts c7b3a91017. Having
libclang.so with a different SONAME than the other LLVM libraries was
causing a lot of confusion for users. Also, this change did not really
acheive it's purpose of allowing apps to use newer versions of
libclang.so without rebuilding, because a new version of libclang.so
requires a new version of libLLVM.so, which does not have a stable ABI.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D129160
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
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
As per P2327R1,
|=, &= and ^= are no longer deprecated in all languages mode.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130421
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
Clang has traditionally allowed C programs to implicitly convert
integers to pointers and pointers to integers, despite it not being
valid to do so except under special circumstances (like converting the
integer 0, which is the null pointer constant, to a pointer). In C89,
this would result in undefined behavior per 3.3.4, and in C99 this rule
was strengthened to be a constraint violation instead. Constraint
violations are most often handled as an error.
This patch changes the warning to default to an error in all C modes
(it is already an error in C++). This gives us better security posture
by calling out potential programmer mistakes in code but still allows
users who need this behavior to use -Wno-error=int-conversion to retain
the warning behavior, or -Wno-int-conversion to silence the diagnostic
entirely.
Differential Revision: https://reviews.llvm.org/D129881
EnumDecl's promotion type is set either to the parsed type or calculated type
after completing its definition. When it's bool type and has no definition,
its promotion type is bool which is not allowed by clang.
Fixes#56560.
Differential Revision: https://reviews.llvm.org/D130210
Utkarsh Saxena