[PATCH] D41553: Support parsing double square-bracket attributes in ObjC

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jan 29 13:50:37 PST 2018


rjmccall added inline comments.


================
Comment at: lib/Parse/ParseObjc.cpp:1434
       MaybeParseGNUAttributes(paramAttrs);
-      ArgInfo.ArgAttrs = paramAttrs.getList();
     }
 
----------------
aaron.ballman wrote:
> rjmccall wrote:
> > ObjC parameter syntax is really its own weird thing.  I think this is the right place to allow attributes, after the parenthesized type but before the parameter-variable name (which is optional).  And of course we also allow them within the parentheses, but hopefully that just falls out from parsing the type.
> Within the parens is tricky -- if the attribute appears immediately after the type, then it appertain to the *type* and not the *declaration*.
> ```
> -(void)Test: (int) [[foo]] i  to:(int [[bar]]) j from: ([[baz]] int) k;
> ```
> I would expect `foo` to appertain to `i`, `bar` to appertain to the type `int`, and `baz` to be ill-formed, which is what will fall out from parsing the type.
As you say, the position at the start of a type-specifier-seq normally applies to the declared entity and so cannot have attributes in an abstract declarator.  The parens production is meant to resemble a cast, which is normally just `'(' type-id ')'`, but this is also part a declaration of a variable.  I don't think it's unnatural to allow declaration attributes after the l-paren, and in practice that's a common place where ObjC programmers write parameter attributes today, but sure, we can conservatively start with only allowing declaration attributes after the r-paren.


https://reviews.llvm.org/D41553





More information about the cfe-commits mailing list