[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Jakub Jelinek --- Fixed for GCC 13.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a282da2243103d79262ca04f5e3a3cc7b9b06935 commit r13-40-ga282da2243103d79262ca04f5e3a3cc7b9b06935 Author: Jakub Jelinek Date: Fri Apr 29 13:50:10 2022 +0200 c++: Improve diagnostics for template args terminated with >= or >>= [PR104319] As mentioned in the PR, for C++98 we have diagnostics that expect >> terminating template arguments to be a mistake for > > (C++11 said it has to be treated that way), while if user trying to spare the spacebar doesn't separate > from following = or >> from following =, the diagnostics is confusing, while clang suggests adding space in between. The following patch does that for >= and >>= too. For some strange reason the error recovery emits further errors, not really sure what's going on because I overwrite the token->type like the code does for the C++11 >> case or for the C++98 >> cases, but at least the first error is nicer (well, for the C++98 nested template case and >>= I need to overwrite it to > and so the = is lost, so perhaps some follow-up errors are needed for that case). 2022-04-29 Jakub Jelinek PR c++/104319 * parser.cc (cp_parser_template_argument): Treat >= like C++98 >> after a type id by setting maybe_type_id and aborting tentative parse. (cp_parser_enclosed_template_argument_list): Handle CPP_GREATER_EQ like misspelled CPP_GREATER CPP_RQ and CPP_RSHIFT_EQ like misspelled CPP_GREATER CPP_GREATER_EQ or CPP_RSHIFT CPP_EQ or CPP_GREATER CPP_GREATER CPP_EQ. (cp_parser_next_token_ends_template_argument_p): Return true also for CPP_GREATER_EQ and CPP_RSHIFT_EQ. * g++.dg/parse/template28.C: Adjust expected diagnostics. * g++.dg/parse/template30.C: New test.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #11 from Jakub Jelinek --- Patch has been posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/589875.html and deferred for gcc 13.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
--- Comment #10 from qingzhe huang ---
Here I have another test case. It involves an anonymous template argument which
confuses me for a lot at the time which clang is doing a great job to clarify
the reason for me.
https://www.godbolt.org/z/YGfMncGeW
template ::value,
bool>=true //there should be a space in ">="
>
struct TestStruct{};
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
--- Comment #9 from Jakub Jelinek ---
Though, the cp_parser_next_token_ends_template_argument_p change can't be
right.
E.g.
struct A{};
A<1>=2> a;
is not A<1> =2> a;
I bet we can't treat at least >= as terminating template argument, perhaps we
could go back to it if tentative parsing with >= didn't work out.
In any case, not a GCC 12 material as not a regression.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #8 from Jakub Jelinek --- Created attachment 52338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52338=edit gcc12-pr104319.patch Improved patch. The error recovery doesn't work well for some reason though as can be seen on the spurious extra errors, unfortunately no idea why is that because the ugly hack of overwriting token->type clearly works at least for the supported C++11 and later case of z> = 0; But at least the first errors are now clearer.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #7 from Jakub Jelinek --- Created attachment 52337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52337=edit gcc12-pr104319.patch Untested fix. That said, now that I think about it, >>= doesn't need to be misspelling of > >=, but can be also misspelling of >> = e.g. with nested template argument.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #6 from qingzhe huang --- But clang can give similar clear message by pointing out the space. Just like ">>" instead "> >" after c++98, I think GCC can do better to recognize ">>=" is possible of "> >=". Just considering even though ">>" is one token, still parser now consider the case of ">" and ">" as to two closing brackets for two nested templates. My point is that even though ">>=" is one token, it doesn't prevent parser from splitting the token into possible two tokens. Not always the longest match algorithms in tokenization. My suggestion is that how about we calculate all possible superset of all other operators. For example, ">>=" is equivalent to ">" and ">=". Or ">>" and "=". there are tokens who is using longest match to return only the longest ones. It is just my naive thought.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #4) > No, whole >>= is one token (CPP_RSHIFT_EQ). Oh you are correct, I misread/misremembered the tokens.
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- No, whole >>= is one token (CPP_RSHIFT_EQ). >=, >>= and >> are the only tokens that start with > character, and I think we >only handle >> specially (e.g. because in C++11 it is valid to have a> instead of a > ).
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 Andrew Pinski changed: What|Removed |Added Summary|better error message for|better error message for |parsing error when >= ends |parsing error when >= or >> |a template variable.|ends a template variable. --- Comment #3 from Andrew Pinski --- (In reply to qingzhe huang from comment #2) > A slightly different case with operator ">=" after template-id causing > identical error message is: https://www.godbolt.org/z/7ajvfM4rb > > #include > > template > constexpr std::size_t zero=0; > > template > constexpr bool Bool=zero>=0; Right in this case >> is the token. these cases just need to be special cased really in the parser itself which is what clang does.
