================
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -std=c2x -verify %s
+
+/* WG14 N3006: Full
+ * Underspecified object declarations
+ */
+
+struct S1 { int x, y; }; // expected-note {{previous definition is
here}}
+union U1 { int a; double b; }; // expected-note {{previous definition is
here}}
+enum E1 { FOO, BAR }; // expected-note {{previous definition is
here}}
+
+auto normal_struct = (struct S1){ 1, 2 };
+auto underspecified_struct = (struct S2 { int x, y; }){ 1, 2 }; //
expected-error {{'struct S2' is defined as an underspecified object
initializer}}
+auto underspecified_struct_redef = (struct S1 { char x, y; }){ 'A', 'B'}; //
expected-error {{redefinition of 'S1'}}
+auto underspecified_empty_struct = (struct S3 { }){ }; //
expected-error {{'struct S3' is defined as an underspecified object
initializer}}
+
+auto normal_union_int = (union U1){ .a = 12 };
+auto normal_union_double = (union U1){ .b = 2.4 };
+auto underspecified_union = (union U2 { int a; double b; }){ .a = 34 };
// expected-error {{'union U2' is defined as an underspecified object
initializer}}
+auto underspecified_union_redef = (union U1 { char a; double b; }){ .a = 'A'
}; // expected-error {{redefinition of 'U1'}}
+auto underspecified_empty_union = (union U3 { }){ };
// expected-error {{'union U3' is defined as an underspecified object
initializer}}
+
+auto normal_enum_foo = (enum E1){ FOO };
+auto normal_enum_bar = (enum E1){ BAR };
+auto underspecified_enum = (enum E2 { BAZ, QUX }){ BAZ }; //
expected-error {{'enum E2' is defined as an underspecified object initializer}}
+auto underspecified_enum_redef = (enum E1 { ONE, TWO }){ ONE }; //
expected-error {{redefinition of 'E1'}}
+auto underspecified_empty_enum = (enum E3 { }){ }; //
expected-error {{'enum E3' is defined as an underspecified object initializer}}
\
+
expected-error {{use of empty enum}}
----------------
AaronBallman wrote:
I think we need additional test coverage for the changes to scope that came
from the paper, but we should already have diagnostics implemented for them. I
read that as changing the behavior of this code:
```
constexpr int i = i;
auto j = j;
```
The only bit I'm not certain of is "... if the same ordinary identifier
declares another entity with a scope that encloses the current block, that
declaration is hidden as soon as the inner declarator is completed".
```
int func() {
struct S { int x, y; };
constexpr int i = (struct T { int a, b; }){0, 1}.a;
struct T t = { 1, 2 };
}
```
so that the use of `struct T` outside of the compound literal is no longer
valid. I'm not certain we *want* to conform to that restriction if we're
deciding we want to accept the use in the compound literal. Again, it's
mysterious behavior for the `constexpr` specifier to change behavior of type
definitions.
https://github.com/llvm/llvm-project/pull/79845
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
