Details
Diff Detail
- Repository
- rC Clang
Event Timeline
As we see. this is not good place to parse attribute((fallthough), which blocks D63260. Maybe @aaron.ballman could help us since he knows this code better..
isDeclarationStatement() returns true for attribute((fallthough)) ;
lib/Parse/ParseStmt.cpp | ||
---|---|---|
102 | Maybe we check if Tok is kw__attribute and look ahead a few tokens to check if attribute name is fallthough in ParseStatementOrDeclarationAfterAttributes. Now, we always fall into if ((getLangOpts().CPlusPlus || getLangOpts().MicrosoftExt || (StmtCtx & ParsedStmtContext::AllowDeclarationsInC) != ParsedStmtContext()) && isDeclarationStatement()) { SourceLocation DeclStart = Tok.getLocation(), DeclEnd; DeclGroupPtrTy Decl = ParseDeclaration(DeclaratorContext::BlockContext, DeclEnd, Attrs); return Actions.ActOnDeclStmt(Decl, DeclStart, DeclEnd); } |
lib/Parse/ParseStmt.cpp | ||
---|---|---|
102 | Then we go to "ParseSimpleDeclaration" -> "ParseDeclarationSpecifier". What is quite strange for me, we do not set "Attrs" in ParseSimpleDeclaration from DS.getAttributes().. |
lib/Parse/ParseStmt.cpp | ||
---|---|---|
102 |
Why not check whether the attribute is a statement attribute or a declaration attribute, rather than tying it to fallthrough specifically? But the result then would be: if it's a statement attribute, we should be trying to parse it as a statement rather than declaration statement; if it's a declaration attribute, we should try to parse as a declaration. This seems very much like spooky action at a distance -- attributes should not dictate whether something is parsed as a decl or a stmt. That said, this really is the right place for that code to go, I think. We've never had a GNU null attribute statement before, so the parser may be written in an inconvenient way to support that (IIRC, we have similar deficiencies with things like attributes appertaining to declaration specifiers -- we don't have attributes that need it yet, so support was never added for it). This may require a bit more surgery to fix up, unfortunately. |
Ok, If we peek a few tokens ahead and check attribute if it is stmt attribute and then we call MaybeParseGNUAttr - this probably would work but are you fine with it as a workaround ?
That still seems like the same spooky action at a distance because it means a statement vs declaration attribute will change the parsing behavior.
Maybe we check if Tok is kw__attribute and look ahead a few tokens to check if attribute name is fallthough in ParseStatementOrDeclarationAfterAttributes.
Now, we always fall into
if ((getLangOpts().CPlusPlus || getLangOpts().MicrosoftExt ||