[Bug c++/104319] New: "parse error of template argument list" due to missing space in ">==", a better error message should be given

[Bug c++/104319] New: "parse error of template argument list" due to missing space in ">==", a better error message should be given

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

            Bug ID: 104319
           Summary: "parse error of template argument list" due to missing
                    space in ">==", a better error message should be given
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

consider following code (https://www.godbolt.org/z/4drb17Pqn):

template<typename T>
struct A{ 
    constexpr static int value=0;
};

template<typename T>
constexpr int Zero=A<T>::value;
static_assert(Zero<int>==0);

<source>:8:15: error: parse error in template argument list
    8 | static_assert(Zero<int>==0);
      |               ^~~~~~~~~~~~
<source>:8:15: error: template argument 1 is invalid
Compiler returned: 1


clang gives much clear reason: 
error: a space is required between a right angle bracket and an equals sign
(use '> =')
static_assert(Zero<int>==0);
                      ^~
                      > =

clearly "Zero<int>" can be considered template id to avoid template argument
list error message.

[Bug c++/104319] better error message for parsing error when >= ends a template variable.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|"parse error of template    |better error message for
                   |argument list" due to       |parsing error when >= ends
                   |missing space in ">==", a   |a template variable.
                   |better error message should |
                   |be given                    |
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-02-01
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed here is a simplified reduced testcase:
template<typename T> int Zero;
void f(void)
{
  Zero<int>=0;
}

--- CUT ----
GCC currently produces:
<source>: In function 'void f()':
<source>:4:3: error: parse error in template argument list
    4 |   Zero<int>=0;
      |   ^~~~~~~~~~~

Clang gives:
<source>:4:11: error: a space is required between a right angle bracket and an
equals sign (use '> =')
  Zero<int>=0;
          ^~
          > =

While MSVC gives:
<source>(4): error C2947: expecting '>' to terminate template-argument-list,
found '>='

ICC gives:
<source>(4): error: expected a ">"
    Zero<int>=0;
            ^


All three are better than GCC's really.

[Bug c++/104319] better error message for parsing error when >= ends a template variable.

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #2 from qingzhe huang <nickhuang99 at hotmail dot com> ---
A slightly different case with operator ">=" after template-id causing
identical error message is: https://www.godbolt.org/z/7ajvfM4rb

#include <utility>

template<typename T>
constexpr std::size_t zero=0;

template<typename T>
constexpr bool Bool=zero<T>>=0;

<source>:7:21: error: parse error in template argument list
    7 | constexpr bool Bool=zero<T>>=0;
      |                     ^~~~~~~~~~
Compiler returned: 1

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

Andrew Pinski <pinskia at gcc dot gnu.org> 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 <pinskia at gcc dot gnu.org> ---
(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 <utility>
> 
> template<typename T>
> constexpr std::size_t zero=0;
> 
> template<typename T>
> constexpr bool Bool=zero<T>>=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.

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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<b<c>>
instead of a<b<c> > ).

[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #6 from qingzhe huang <nickhuang99 at hotmail dot com> ---
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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52337&action=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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52338&action=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<A<int>> = 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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though, the cp_parser_next_token_ends_template_argument_p change can't be
right.
E.g.
struct <int N> 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.

[nickhuang99 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #10 from qingzhe huang <nickhuang99 at hotmail dot com> ---
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 <typename T=int, 
    std::enable_if_t<std::is_integral<T>::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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a282da2243103d79262ca04f5e3a3cc7b9b06935

commit r13-40-ga282da2243103d79262ca04f5e3a3cc7b9b06935
Author: Jakub Jelinek <jakub@redhat.com>
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  <jakub@redhat.com>

            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.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for GCC 13.