================
@@ -1136,6 +1136,20 @@ void Parser::AnnotateExistingDecltypeSpecifier(const
DeclSpec &DS,
// make sure we have a token we can turn into an annotation token
if (PP.isBacktrackEnabled()) {
PP.RevertCachedTokens(1);
+ if (DS.getTypeSpecType() == TST_error && PP.hasCachedTokenLocation()) {
----------------
AaronBallman wrote:
I don't think this fix is correct; we should not have to track cached token
locations like this. I did more investigation and it looks like we're several
layers deep in hacks.
The issue is that member pointers are getting special handling which includes
looking for a `decltype` token, but it doesn't care whether that `decltype` is
valid or not; if the token is there, it's assumed to be parsed as a `decltype`
specifier:
https://github.com/llvm/llvm-project/blob/aab7e0b08d30ddca5858069a4c14c1ea3da042e6/clang/lib/Parse/ParseDecl.cpp#L6493
Adding an extra check for a `(` as the next token resolves the issues and
causes no additional test failures.
(FWIW, we are finding that LLMs do a *terrible* job of correctly addressing
failed assertions. I see you disclosed LLM tool use, so that's something you
should be aware of for future PRs. If it's fixing a failed assertion, assume
the LLM will point you in the wrong direction.)
https://github.com/llvm/llvm-project/pull/211221
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
