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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
