This is an archive of the discontinued LLVM Phabricator instance.

Better diagnostics for anonymous bit-fields with attributes or an initializer
ClosedPublic

Authored by aaron.ballman on Sep 25 2020, 12:48 PM.

Details

Summary

The C++ grammar allows you to specify an attribute list on an anonymous bit-field, but we were not properly parsing that case. This would lead to a rejects-valid diagnostic with code like:

struct A {
  int x, [[]] : 0;
};

This patch addresses it by optionally parsing an attribute specifier in the case the identifier is elided. This fixes PR46562.

Diff Detail

Event Timeline

aaron.ballman requested review of this revision.Sep 25 2020, 12:48 PM
aaron.ballman created this revision.
aaron.ballman edited the summary of this revision. (Show Details)

I think we established rough consensus in CWG (at least, no one objected) that this is a grammar bug -- there's nothing for these attributes to appertain to, so they shouldn't be permitted. Unless CWG indicates it wants to change direction here I think we should continue to reject.

I think we established rough consensus in CWG (at least, no one objected) that this is a grammar bug -- there's nothing for these attributes to appertain to, so they shouldn't be permitted. Unless CWG indicates it wants to change direction here I think we should continue to reject.

I agree -- are you okay if I change this around to drop support for the brace or init list for an anonymous bit-field as part of that consensus? If so, would you like me to ask Mike for a core issue # to track that change against?

aaron.ballman planned changes to this revision.Sep 26 2020, 5:33 AM
aaron.ballman retitled this revision from Correctly parse attributes on the declaration of an anonymous bit-field to Better diagnostics for anonymous bit-fields with attributes or an initializer.

I've updated the patch to continue to reject attributes on anonymous bit-fields, but with a better diagnostic. In addition, I changed how we handle anonymous bit-fields with an initializer (based on discussion on the Core reflector) -- instead of rejecting the construct as a semantic issue, I reject it at the parser level with a similar diagnostic (I went with "in-class initializer" because that's used by other parser diagnostics, but I'm fine with either formulation).

rsmith added inline comments.Sep 27 2020, 6:24 PM
clang/include/clang/Basic/DiagnosticParseKinds.td
875–876

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.)

clang/lib/Parse/ParseDecl.cpp
4132–4134

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.)

clang/lib/Parse/ParseDeclCXX.cpp
2311–2318

Please mention that this is a proposed bugfix, not the standard grammar.

2321–2323

(Same comment as for the C side of things.)

aaron.ballman marked 4 inline comments as done.

Updated based on review feedback.

clang/include/clang/Basic/DiagnosticParseKinds.td
875–876

Sounds good to me, and I can do the rest of the cleanup as an NFC commit once this lands.

clang/lib/Parse/ParseDecl.cpp
4132–4134

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.

rsmith accepted this revision.Sep 28 2020, 2:24 PM

Thanks!

clang/lib/Parse/ParseDecl.cpp
4126

I think this change is redundant now.

clang/lib/Parse/ParseDeclCXX.cpp
2317

Similarly here, I think the check for an attribute specifier is now redundant.

This revision is now accepted and ready to land.Sep 28 2020, 2:24 PM
aaron.ballman closed this revision.Sep 29 2020, 1:33 PM
aaron.ballman marked 2 inline comments as done.

Thank you for the reviews, I've committed in 538762fef0b662048be2a261ebc12da249efa977

clang/lib/Parse/ParseDecl.cpp
4126

Ah, good catch! I've corrected this (and the other one).