[PATCH] D33339: Fix valid-for-expr ellipses eaten as invalid decl

[Richard Smith via Phabricator via cfe-commits]

rsmith added a comment.

Should I assume our "misplaced ellipsis" diagnostic requires that we disambiguate the ill-formed ellipsis-after-declarator-id as a declaration in some cases? If so, do we have tests for that somewhere?



================
Comment at: include/clang/Parse/Parser.h:2138
+  TPResult TryParseDeclarator(bool mayBeAbstract, bool mayHaveIdentifier = true,
+                              bool mayHaveTrailingStrayEllipsis = true);
   TPResult
----------------
Given that this flag is enabling parsing of things that are *not* valid declarators, I think the default should be the other way around. If some calling code believes it's safe to parse a trailing ellipsis as part of a declarator, it should be explicitly opting into that.


================
Comment at: lib/Parse/ParseTentative.cpp:944
+        (mayHaveTrailingStrayEllipsis ||
+         !(NextToken().is(tok::r_paren) || NextToken().is(tok::comma))))
       ConsumeToken();
----------------
hubert.reinterpretcast wrote:
> The check for what qualifies as "trailing" is not the strongest, but I find it to be the most straightforward change that should do the job. One alternative is to track whether an ellipsis was consumed within the current loop iteration.
Use `!NextToken().isOneOf(tok::r_paren, tok::comma)` here.


https://reviews.llvm.org/D33339