[PATCH] D17149: Consolidate and improve the handling of built-in feature-like macros
Andy Gibbs via cfe-commits
cfe-commits at lists.llvm.org
Mon Apr 4 02:05:38 PDT 2016
AndyG added inline comments.
Comment at: lib/Lex/PPMacroExpansion.cpp:1456-1457
@@ +1455,4 @@
+ // Parse next non-comment, non-annotation token.
+ do PP.LexUnexpandedNonComment(Tok); while (Tok.isAnnotation());
> If we get an annotation token here, we should reject it, not silently ignore it. Also, we shouldn't see comment tokens here (we shouldn't be doing macro expansion with comments enabled); you should call `LexUnexpandedToken` rather than `LexUnexpandedNonComment`.
Ok, annotation tokens are not ignored, but drop down into `Op` and can be handled there.
Comment at: lib/Lex/PPMacroExpansion.cpp:1481-1484
@@ +1480,6 @@
+ auto Diag = PP.Diag(Tok.getLocation(), diag::err_pp_unexpected_after);
+ if (IdentifierInfo *LastII = LastTok.getIdentifierInfo())
+ Diag << LastII;
+ Diag << LastTok.getKind();
+ Diag << tok::l_paren << LastTok.getLocation();
> The only way we can get here without already having a value or producing a diagnostic is if this is the first token inside the parens. So this will always say "unexpected '(' after '('".
> I think it would be better to always `break` here after incrementing `ParenDepth` (even when `!Result.hasValue()`), and let `Op` produce the relevant diagnostic for this case.
I've handled this via a specific diagnostic message: "nested parentheses not permitted in %0" where %0 is the macro name. I would prefer this to bringing the error checking into `Op` since this would complicate the implementation of `Op` needlessly IMHO. `Op` should be as slimline as possible.
More information about the cfe-commits