[PATCH] D88333: Better diagnostics for anonymous bit-fields with attributes or an initializer

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:875-876
   "C++ standards before C++20">, InGroup<CXXPre20Compat>, DefaultIgnore;
+def err_anon_bitfield_member_init : Error<
+  "anonymous bit-field cannot have an in-class initializer">;
 def err_incomplete_array_member_init: Error<
----------------
rsmith wrote:
> Please retain the diagnostic wording using proper standard terminology; the other diagnostics say "in-class initializer" because they predate the existence of the standard terminology and haven't been fixed yet. (Fixing them -- and renaming the corresponding functions throughout Clang -- would be great if you feel so inclined.)
Sounds good to me, and I can do the rest of the cleanup as an NFC commit once this lands.


================
Comment at: clang/lib/Parse/ParseDecl.cpp:4127-4129
+      // Anonymous bit-fields cannot specify attributes; the attributes
+      // appertain to the type specifier for the bit-field instead. Provide a
+      // kinder parsing error than if we just let parsing happen organically.
----------------
rsmith wrote:
> I think this will regress our diagnostics for this (probably more common) case:
> 
> ```
> struct X { 
>   int a, [[attr]] b;
> };
> ```
> 
> Instead, how about we unconditionally `DiagnoseAndSkipCXX11Attributes()` before and after we parse GNU attributes in the `if (!FirstDeclarator)` check up above? (Aside: we should probably be better about handling mixed sequences of GNU and C++11 attributes in general.)
Good catch, I've made the changes. And I agree about attribute parsing order; I'd really like to take another stab at fixing that if I get the chance.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88333/new/

https://reviews.llvm.org/D88333