[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