llvm-project/clang/test/SemaCXX/c99.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

71 lines
2.3 KiB
C++
Raw Normal View History

[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
2019-08-31 06:52:55 +08:00
// RUN: %clang_cc1 -fsyntax-only -pedantic -verify=expected,cxx17 -std=c++17 %s
// RUN: %clang_cc1 -fsyntax-only -pedantic -verify=expected,cxx20 -std=c++2a %s
// cxx17-warning@* 0+{{designated initializers are a C++20 extension}}
void f1(int i[static 5]) { // expected-error{{C99}}
}
struct Point { int x; int y; int z[]; }; // expected-warning{{flexible array members are a C99 feature}}
[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
2019-08-31 06:52:55 +08:00
Point p1 = { .x = 17,
y: 25 }; // expected-warning{{use of GNU old-style field designator extension}}
Point p2 = {
.x = 17, // expected-warning {{mixture of designated and non-designated initializers in the same initializer list is a C99 extension}}
25 // expected-note {{first non-designated initializer}}
};
Point p3 = {
.x = 17, // expected-note {{previous initialization is here}}
.x = 18, // expected-warning {{initializer overrides prior initialization of this subobject}}
};
Point p4 = {
.x = 17, // expected-warning {{mixture of designated and non-designated initializers in the same initializer list is a C99 extension}}
25, // expected-note {{first non-designated initializer}}
// expected-note@-1 {{previous initialization is here}}
.y = 18, // expected-warning {{initializer overrides prior initialization of this subobject}}
};
int arr[1] = {[0] = 0}; // expected-warning {{array designators are a C99 extension}}
struct Pt { int x, y; };
struct Rect { Pt tl, br; };
Rect r = {
.tl.x = 0 // expected-warning {{nested designators are a C99 extension}}
};
struct NonTrivial {
NonTrivial();
~NonTrivial();
};
struct S {
int a;
NonTrivial b;
};
struct T {
S s;
};
S f();
T t1 = {
.s = f()
};
// It's important that we reject this; we would not destroy the existing
// 'NonTrivial' object before overwriting it (and even calling its destructor
// would not necessarily be correct).
T t2 = {
.s = f(), // expected-note {{previous}}
.s.b = NonTrivial() // expected-error {{initializer would partially override prior initialization of object of type 'S' with non-trivial destruction}}
// expected-warning@-1 {{nested}}
};
// FIXME: It might be reasonable to accept this.
T t3 = {
.s = f(), // expected-note {{previous}}
.s.a = 0 // expected-error {{initializer would partially override prior initialization of object of type 'S' with non-trivial destruction}}
// expected-warning@-1 {{nested}}
};