llvm-project/clang/test/SemaCXX/constexpr-value-init.cpp

47 lines
1.2 KiB
C++
Raw Normal View History

// RUN: %clang_cc1 %s -Wno-uninitialized -std=c++11 -fsyntax-only -verify
struct A {
constexpr A() : a(b + 1), b(a + 1) {} // expected-note {{outside its lifetime}}
int a;
int b;
};
struct B {
A a;
};
constexpr A a; // ok, zero initialization precedes static initialization
void f() {
constexpr A a; // expected-error {{constant expression}} expected-note {{in call to 'A()'}}
}
constexpr B b1; // ok
constexpr B b2 = B(); // ok
static_assert(b2.a.a == 1, "");
static_assert(b2.a.b == 2, "");
struct C {
int c;
};
struct D : C { int d; };
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
2015-04-17 16:32:38 +08:00
constexpr C c1; // expected-error {{without a user-provided default constructor}}
constexpr C c2 = C(); // ok
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
2015-04-17 16:32:38 +08:00
constexpr D d1; // expected-error {{without a user-provided default constructor}}
constexpr D d2 = D(); // ok with DR1452
static_assert(D().c == 0, "");
static_assert(D().d == 0, "");
struct V : virtual C {};
template<typename T> struct Z : T {
constexpr Z() : V() {}
};
constexpr int n = Z<V>().c; // expected-error {{constant expression}} expected-note {{non-literal type 'Z<V>'}}
struct E {
A a[2];
};
constexpr E e; // ok
static_assert(e.a[0].a == 1, "");
static_assert(e.a[0].b == 2, "");
static_assert(e.a[1].a == 1, "");
static_assert(e.a[1].b == 2, "");