aaron.ballman added a comment. In D64838#1592118 <https://reviews.llvm.org/D64838#1592118>, @Nathan-Huckleberry wrote:
> In D64838#1592111 <https://reviews.llvm.org/D64838#1592111>, @aaron.ballman > wrote: > > > In D64838#1589770 <https://reviews.llvm.org/D64838#1589770>, > > @Nathan-Huckleberry wrote: > > > > > The main problem that we have is that the `__attribute__` token always > > > causes the parser to read the line as a declaration. Then the declaration > > > parser handles reading the attributes list. > > > > > > This case demonstrates the problem: > > > > > > void foo() { > > > __attribute__((address_space(0))) *x; > > > } > > > > > > > > > If the attribute token is read beforehand this code just becomes `*x` and > > > is parsed as a dereference of an undefined variable when it should > > > actually be a declaration. > > > > > > Maybe the best solution is to pull the attributes parsing out to > > > `ParseStatementOrDeclaration` then pass those attributes through to > > > following functions. > > > When the determination is made whether a line is a declaration or a > > > statement the attributes list can be looked at to determine if the > > > attributes are statement or declaration attributes and continue > > > accordingly. Maybe throwing a warning if mixing of declaration and > > > statement attributes occur. > > > > > > Does that sound like a good solution? > > > > > > Please see the discussion in https://reviews.llvm.org/D63299#inline-564887 > > -- if I understand your approach properly, this approach leads to spooky > > action at a distance, where the name of the attribute dictates whether > > something is a statement or a declaration. I'm not comfortable with that. > > There's no reason we could not have an attribute that is both a statement > > attribute and a declaration attribute, and how would *that* parse? > > > > I think this requires some deeper surgery in the parsing logic so that > > attributes do not impact whether something is treated as a declaration or a > > statement. The parser should parse attributes first, keep them around for a > > while, and attach them to either the decl or the statement at a later point. > > > Any idea how to fix the problem in the code sample I gave? The addition of > the attributes token causes code to be read as a declaration and without the > token it is read as a unary operator. I would start by trying to have `Parser::ParseStatementOrDeclarationAfterAttributes()` parse the GNU-style attributes if the `__attribute__` token is encountered, adding to the `Attrs`, and then retrying the loop. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64838/new/ https://reviews.llvm.org/D64838 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
