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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
