This way we can use their address, which is necessary in some
scenarios. This requires us to create different descriptors
for dummy arrays so we can get the diagnostics right.
Some time ago, I did a similar patch for local variables.
Initializing global variables can fail as well:
```c++
constexpr int a = 1/0;
static_assert(a == 0);
```
... would succeed in the new interpreter, because we never saved the
fact that `a` has not been successfully initialized.
This fixes a long-standing FIXME item.
Unfortunately it changes the diagnostic output of the tests added in
`cxx23.cpp`, but they were wrong before and are wrong after, so no big
deal.
EvaluateAsConstantExpr() uses ::EvaluateInPlace() directly, which does
not use the new interpreter if requested. Do it here, which is the same
pattern we use in EvaluateAsInitializer.
Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.
Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.
This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.
RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565
This adds `IntegralAP` backing the two new primtypes `IntAP` (unsigned
arbitrary-precision int) and `IntAPS` (same but signed).
We use this for `int128` support (which isn't available on all host
systems we support AFAIK) and I think we can also use this for `_BitInt`
later.
This reverts commit 491b2810fb7fe5f080fa9c4f5945ed0a6909dc92.
This change broke valid code and generated incorrect diagnostics, see
https://reviews.llvm.org/D155064
This patch makes clang diagnose extensive cases of consteval if and is_constant_evaluated usage that are tautologically true or false.
This introduces a new IsRuntimeEvaluated boolean flag to Sema::ExpressionEvaluationContextRecord that means the immediate appearance of if consteval or is_constant_evaluated are tautologically false(e.g. inside if !consteval {} block or non-constexpr-qualified function definition body)
This patch also pushes new expression evaluation context when parsing the condition of if constexpr and initializer of constexpr variables so that Sema can be aware that the use of consteval if and is_consteval are tautologically true in if constexpr condition and constexpr variable initializers.
BEFORE this patch, the warning for is_constant_evaluated was emitted from constant evaluator. This patch moves the warning logic to Sema in order to diagnose tautological use of is_constant_evaluated in the same way as consteval if.
This patch separates initializer evaluation context from InitializerScopeRAII.
This fixes a bug that was happening when user takes address of function address in initializers of non-local variables.
Fixes https://github.com/llvm/llvm-project/issues/43760
Fixes https://github.com/llvm/llvm-project/issues/51567
Reviewed By: cor3ntin, ldionne
Differential Revision: https://reviews.llvm.org/D155064
Predefined macro FUNCTION (and __FUNC__) in clang is not returning the
same string than MS for templated functions.
See https://godbolt.org/z/88n1rGs3b
For this test case MSVC is returning:
function: TestClass<class UnitTestNative>::TestClass
func: TestClass
---------
Co-authored-by: Reid Kleckner <rnk@google.com>
We didn't call the function explicitly in a static_assert() statement
and the checkPotentialConstantExpression() invocation quietly aborted
early because of the missing initializer for A::a.
Fix this by calling ignoredExprs() explicitly.
Differential Revision: https://reviews.llvm.org/D149965
Ignore the expressions and re-do the tests without all the "result
ignored" expected warnings. Those are expected, given the nature of the
tests.
Differential Revision: https://reviews.llvm.org/D149831
