[clang] [Clang] allow GNU attrs before bit-field width in member declarators (PR #185322)

[Aaron Ballman via cfe-commits]

================
@@ -2512,11 +2512,15 @@ bool Parser::ParseCXXMemberDeclaratorBeforeInitializer(
   else
     DeclaratorInfo.SetIdentifier(nullptr, Tok.getLocation());
 
+  const bool IsFunctionDeclarator = DeclaratorInfo.isFunctionDeclarator();
+  if (!IsFunctionDeclarator)
+    MaybeParseGNUAttributes(DeclaratorInfo, &LateParsedAttrs);
----------------
AaronBallman wrote:

I think we need to figure out which declarators cannot have an attribute following them, because GNU attributes are not consistent:
```
int a __attribute__((deprecated)) = 12; // Acceptable after this declarator
int b __attribute__((deprecated))(); // Not acceptable after this declarator
```
https://godbolt.org/z/G55M5YeT1

GCC has some documentation on this which suggests inconsistency is expected but may change in the future: https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#All-other-attributes Specifically:

> Otherwise, an attribute specifier appears as part of a declaration, counting declarations of unnamed parameters and type names, and relates to that declaration (which may be nested in another declaration, for example in the case of a parameter declaration), or to a particular declarator within a declaration.

"or to a particular declarator within a declarator" suggests to me there's a desire to accept on all declarators, though it's unclear whether this means `attr declarator` or `declarator attr` or both. It seems "both" maybe? https://godbolt.org/z/GsPEc6MPW

This is starting to sound like a pretty significant research project though. So for just the bit-field case, I think the targeted fix is reasonable. CC @erichkeane for a second opinion on that though.

https://github.com/llvm/llvm-project/pull/185322