Change Details

https://bugs.llvm.org/show_bug.cgi?id=42049 Currently clang, in the following code, when tentatively parsing the template-argument-list recognizes the error, and skips till the semi-colon. But when annotating the broken decltype specifier token (in an effort to backtrack gracefully and continue parsing), it appears we should include all the cached tokens that were skipped until the sem-colon as an annotated subset of our annot_decltype token. Not doing so results in a book-keeping assertion failure. ``` void f() { g<decltype>(); } ``` This situation did not seem to arise prior to https://github.com/llvm/llvm-project/commit/b23c5e8c3df850177449268c5ca7dbf986157525 - which implements assumption of names as function templates even if no function with that name is found.

https://bugs.llvm.org/show_bug.cgi?id=42049 Currently clang, in the following code, when tentatively parsing the template-argument-list recognizes the error, and skips till the semi-colon. But when annotating the broken decltype specifier token (in an effort to backtrack gracefully and continue parsing), it appears we manually sync up the cache position with the last token that we think is part of the (broken) decltype construct. Not doing so results in a book-keeping assertion failure. ``` void f() { g<decltype>(); } ``` This situation did not seem to arise prior to https://github.com/llvm/llvm-project/commit/b23c5e8c3df850177449268c5ca7dbf986157525 - which implements assumption of names as function templates even if no function with that name is found.

https://bugs.llvm.org/show_bug.cgi?id=42049 Currently clang, in the following code, when tentatively parsing the template-argument-list recognizes the error, and skips till the semi-colon. But when annotating the broken decltype specifier token (in an effort to backtrack gracefully and continue parsing), it appears we should include allmanually sync up the cached tokens that were skipped until position with the sem-colon as an annotated subselast token that we think is part of our annot_the (broken) decltype tokenconstruct. Not doing so results in a book-keeping assertion failure. ``` void f() { g<decltype>(); } ``` This situation did not seem to arise prior to https://github.com/llvm/llvm-project/commit/b23c5e8c3df850177449268c5ca7dbf986157525 - which implements assumption of names as function templates even if no function with that name is found.