================
@@ -1,13 +1,58 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only
// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -verify=gnu -fsyntax-only
-Wgnu-flexible-array-union-member -Wgnu-empty-struct
+// RUN: %clang_cc1 %s -verify=microsoft -fsyntax-only -fms-compatibility
-Wmicrosoft
// The test checks that an attempt to initialize union with flexible array
// member with an initializer list doesn't crash clang.
-union { char x[]; } r = {0}; // c-error {{flexible array member 'x' in a union
is not allowed}}
+union { char x[]; } r = {0}; /* gnu-warning {{flexible array member 'x' in a
union is a GNU extension}}
+ microsoft-warning {{flexible array member 'x'
in a union is a Microsoft extension}}
+ */
----------------
hvdijk wrote:
I do not see any obvious cases where the code does the wrong thing, sure, I
agree with you on that, but as far as I can find, we do not have *any* test for
"initialization of flexible array member is not allowed" being correctly
emitted for nested unions containing flexible array members, either currently
or after this PR. `flexible-array-init.c` contains tests for this for nested
structs containing flexible array members, but not for unions. Previously,
these would have implicitly been handled by flexible array members being
disallowed in unions in the first place, at least for C, but as you are
enabling them now, that no longer applies.
https://github.com/llvm/llvm-project/pull/84428
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
