[PATCH] D91821: Fix PR42049 - Crash when parsing bad decltype use within template argument list after name assumed to be a function template

[Faisal Vali via Phabricator via cfe-commits]

faisalv updated this revision to Diff 309809.
faisalv edited the summary of this revision.
faisalv added a comment.

Per Richard's suggestion, instead of including the cached tokens into the decltype annotation, i revert the cache to match the end of where we think the (broken) decltype annotated token should end.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91821/new/

https://reviews.llvm.org/D91821

Files:
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/Parser/PR42049.cpp


Index: clang/test/Parser/PR42049.cpp
===================================================================
--- /dev/null
+++ clang/test/Parser/PR42049.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// https://bugs.llvm.org/show_bug.cgi?id=42049
+
+void f() {
+  g<decltype>(); // expected-error  {{use of undeclared identifier}} expected-error {{expected}}
+  g2<decltype x; // expected-error 2{{expected}} expected-note {{to match}}
+}                   
+
+template<class T> void f2() {
+  g<decltype>(); // expected-error {{use of undeclared identifier}} expected-error {{expected}}
+  g2<decltype x; // expected-error 2{{expected}} expected-note {{to match}}
+}
+
Index: clang/lib/Parse/ParseDeclCXX.cpp
===================================================================
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -1048,11 +1048,15 @@
   if (PP.isBacktrackEnabled()) {
     PP.RevertCachedTokens(1);
     if (DS.getTypeSpecType() == TST_error) {
-      // We encountered an error in parsing 'decltype(...)' so lets annotate all
-      // the tokens in the backtracking cache - that we likely had to skip over
-      // to get to a token that allows us to resume parsing, such as a
-      // semi-colon.
-      EndLoc = PP.getLastCachedTokenLocation();
+      // We encountered an error in parsing 'decltype(...)' so lets revert
+      // the tokens (that we likely had to skip over to get to a stop token such
+      // as a semi-colon) in the backtracking cache to the EndLoc of where we
+      // think the decltype specifier tokens should have ended. Since these
+      // tokens are in the same token cache, their SourceLocations must have the
+      // same FileID and so should have well defined behavior when comparing.
+      assert(EndLoc <= PP.getLastCachedTokenLocation());
+      while (EndLoc != PP.getLastCachedTokenLocation())
+        PP.RevertCachedTokens(1);
     }
   }
   else


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D91821.309809.patch
Type: text/x-patch
Size: 1954 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20201207/81433b2e/attachment.bin>