[PATCH] D37436: Initial implementation of C attributes (WG14 N2137)

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Oct 7 10:08:09 PDT 2017


aaron.ballman added inline comments.


================
Comment at: clang/lib/Parse/ParseDecl.cpp:5973-5974
+
+    // If there are attributes following the identifier list, parse them and 
+    // prohibit them.
+    MaybeParseCXX11Attributes(FnAttrs);
----------------
rsmith wrote:
> Do you anticipate people trying this? Is the concern here that a function declarator can normally be followed by attributes, and so consistency might imply that we allow attributes on the function declarator after an identifier-list instead?
I don't anticipate this being a common thing for people to try, but it is to prevent an ambiguity:
```
void fp(a, b) [[foo]] int a, b; { }
```
Does [[foo]] appertain to the function type or to the declarations `a` and `b`. N2165 prohibits attributes from appearing in this location.


================
Comment at: clang/lib/Parse/ParseTentative.cpp:592
                                   bool OuterMightBeMessageSend) {
-  if (Tok.is(tok::kw_alignas))
+  if (Tok.is(tok::kw_alignas) && getLangOpts().CPlusPlus11)
     return CAK_AttributeSpecifier;
----------------
rsmith wrote:
> This change is redundant. We wouldn't lex a `kw_alignas` token outside C++11.
Ah, I thought that we would hit this case for `_Alignas` as well, but I see that's a different keyword. Just to double-check -- we don't expect `-fdouble-square-bracket-attributes` to enable `alignas` in C++98, correct?


https://reviews.llvm.org/D37436





More information about the cfe-commits mailing list