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 ...

DR616, and part of P0135R1: member access (or pointer-to-member access) on a
temporary produces an xvalue, not a prvalue. Support this by materializing the
temporary prior to performing the member ac

DR616, and part of P0135R1: member access (or pointer-to-member access) on a
temporary produces an xvalue, not a prvalue. Support this by materializing the
temporary prior to performing the member access.

llvm-svn: 288563

show more ...

Fix implementation of the likely resolution of core issue 253 to support class
based arrays. Patch by Ian Tessier!

Differential Review: https://reviews.llvm.org/D25974

llvm-svn: 285430

Implement the likely resolution of core issue 253.

C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit

Implement the likely resolution of core issue 253.

C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."

clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).

Fixes PR23381.

http://reviews.llvm.org/D16552

llvm-svn: 261297

show more ...

Move fixit for const init from note to diag, weaken to warning in MS mode.

r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for comp

Move fixit for const init from note to diag, weaken to warning in MS mode.

r235046 turned "extern __declspec(selectany) int a;" from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain something
like

struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;

This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with

d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor

(cl.exe just doesn't implement this rule, independent of selectany.)

To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.

Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.

This is the alternative, original fix for PR20208 that got reviewed in the
thread "[patch] Improve diagnostic on default-initializing const variables
(PR20208)". This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.

llvm-svn: 235166

show more ...

Improve diagnostic on default-initializing const variables (PR20208).

This tweaks the diagnostic wording slighly, and adds a fixit on a note.
An alternative would be to add the fixit directly on the

Improve diagnostic on default-initializing const variables (PR20208).

This tweaks the diagnostic wording slighly, and adds a fixit on a note.
An alternative would be to add the fixit directly on the diagnostic, see
the review thread linked to from the bug for a few notes on that approach.

llvm-svn: 213725

show more ...

Fix a tranche of comment, test and doc typos

llvm-svn: 196510

Modify the uninitialized field visitor to detect uninitialized use across the
fields in the class. This allows a better checking of member intiailizers and
in class initializers in regards to initia

Modify the uninitialized field visitor to detect uninitialized use across the
fields in the class. This allows a better checking of member intiailizers and
in class initializers in regards to initialization ordering.

For instance, this code will now produce warnings:

class A {
int x;
int y;
A() : x(y) {} // y is initialized after x, warn here
A(int): y(x) {} // default initialization of leaves x uninitialized, warn here
};

Several test cases were updated with -Wno-uninitialized to silence this warning.

llvm-svn: 191068

show more ...

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

llvm-svn: 180603

PR12012: Fix a regression in r150419 where we would try (and fail) to
zero-initialize class types with virtual bases when constant-evaluating an
initializer.

llvm-svn: 150770

Update constexpr implementation to match CWG's chosen approach for core issues
1358, 1360, 1452 and 1453.
- Instantiations of constexpr functions are always constexpr. This removes the
need for s

Update constexpr implementation to match CWG's chosen approach for core issues
1358, 1360, 1452 and 1453.
- Instantiations of constexpr functions are always constexpr. This removes the
need for separate declaration/definition checking, which is now gone.
- This makes it possible for a constexpr function to be virtual, if they are
only dependently virtual. Virtual calls to such functions are not constant
expressions.
- Likewise, it's now possible for a literal type to have virtual base classes.
A constexpr constructor for such a type cannot actually produce a constant
expression, though, so add a special-case diagnostic for a constructor call
to such a type rather than trying to evaluate it.
- Classes with trivial default constructors (for which value initialization can
produce a fully-initialized value) are considered literal types.
- Classes with volatile members are not literal types.
- constexpr constructors can be members of non-literal types. We do not yet use
static initialization for global objects constructed in this way.

llvm-svn: 150359

show more ...

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 ...

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

llvm-svn: 147271