C++ DR2026: static storage duration variables are not zeroed before
constant initialization.

Removing this zeroing regressed our code generation in a few cases, also
fixed here. We now compute wheth

C++ DR2026: static storage duration variables are not zeroed before
constant initialization.

Removing this zeroing regressed our code generation in a few cases, also
fixed here. We now compute whether a variable has constant destruction
even if it doesn't have a constant initializer, by trying to destroy a
default-initialized value, and skip emitting a trivial default
constructor for a variable even if it has non-trivial (but perhaps
constant) destruction.

show more ...

[c++20] Implement semantic restrictions for C++20 designated
initializers.

This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension

[c++20] Implement semantic restrictions for C++20 designated
initializers.

This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:

* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)

* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.

* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.

* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.

* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).

This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.

This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.

Differential Revision: https://reviews.llvm.org/D59754

llvm-svn: 370544

show more ...

Revert "Lexer: always allow imaginary constants in GNU mode."

This reverts r310423. It was committed by mistake, I intended to commit the
improved diagnostics for implicit conversions instead.

llvm

Revert "Lexer: always allow imaginary constants in GNU mode."

This reverts r310423. It was committed by mistake, I intended to commit the
improved diagnostics for implicit conversions instead.

llvm-svn: 310426

show more ...

Lexer: always allow imaginary constants in GNU mode.

llvm-svn: 310423

PR17381: Treat undefined behavior during expression evaluation as an unmodeled
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.

This caused a di

PR17381: Treat undefined behavior during expression evaluation as an unmodeled
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.

This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.

This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:

float f = 1e100;

are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.

llvm-svn: 254574

show more ...

Revert "Don't require -re suffix on -verify directives with regexes."

This patch was submitted to the list for review and didn't receive a LGTM.

(In fact one explicit objection and one query were r

Revert "Don't require -re suffix on -verify directives with regexes."

This patch was submitted to the list for review and didn't receive a LGTM.

(In fact one explicit objection and one query were raised.)

This reverts commit r197295.

llvm-svn: 197299

show more ...

Don't require -re suffix on -verify directives with regexes.

Differential Revision: http://llvm-reviews.chandlerc.com/D2392

llvm-svn: 197295

C++1y: support simple variable assignments in constexpr functions.

llvm-svn: 180603

Add triples to these tests to keep them working on Windows,
where wchar_t is only 16 bits wide.

llvm-svn: 154072

Fix assertions and wrong output from StmtPrinter's string literal printing.
String literals (including unicode ones) can contain non-Unicode codepoints
if they were written using \x or similar. Write

Fix assertions and wrong output from StmtPrinter's string literal printing.
String literals (including unicode ones) can contain non-Unicode codepoints
if they were written using \x or similar. Write those out using \x, but be
careful that the following character can't be misinterpreted as part of the
\x escape sequence. Convert UTF-16 surrogate pairs back to codepoints before
rendering them.

llvm-svn: 154069

show more ...

Teach APValue printer to print boolean 0 and 1 as 'false' and 'true'. Fix up
some calling code to actually pass in a non-null type, to avoid a crash.

llvm-svn: 153358

Address Richard's review comments on r147561 (Evaluate support for address-of-label differences).

llvm-svn: 147631

Add assertion to char32_t that the value is valid, as suggested by Jordy Rose.
Add a test that such characters don't make it through to StringLiteral objects
in error recovery.

llvm-svn: 147438

Fix crash when trying to pretty-print unicode or wide string literals.

llvm-svn: 147385

Unrevert r147271, reverted in r147361.

Also temporarily remove the assumption from IR gen that we can emit IR for every
constant we can fold, since it isn't currently true in C++11, to fix PR11676.

Unrevert r147271, reverted in r147361.

Also temporarily remove the assumption from IR gen that we can emit IR for every
constant we can fold, since it isn't currently true in C++11, to fix PR11676.

Original comment from r147271:

constexpr: perform zero-initialization prior to / instead of performing a
constructor call when appropriate. Thanks to Eli for spotting this.

llvm-svn: 147384

show more ...

Revert r147271. This fixes PR11676.

llvm-svn: 147362

constexpr: perform zero-initialization prior to / instead of performing a
constructor call when appropriate. Thanks to Eli for spotting this.

llvm-svn: 147271

constexpr: diagnostic improvements for invalid lvalue-to-rvalue conversions in
constant expressions.

llvm-svn: 147035

constexpr handling improvements. Produce detailed diagnostics when a 'constexpr'
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initiali

constexpr handling improvements. Produce detailed diagnostics when a 'constexpr'
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.

Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:

extern const int a;
const int n = a;
const int a = 5;
int arr[n];

Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.

llvm-svn: 146856

show more ...

C++11 constexpr: Add note stacks containing backtraces if constant evaluation
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control

C++11 constexpr: Add note stacks containing backtraces if constant evaluation
fails within a call to a constexpr function. Add -fconstexpr-backtrace-limit
argument to driver and frontend, to control the maximum number of notes so
produced (default 10). Fix APValue printing to be able to pretty-print all
APValue types, and move the testing for this functionality from a unittest to
a -verify test now that it's visible in clang's output.

llvm-svn: 146749

show more ...