This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Mark Mitchell wrote: > * 18140 > > This was a rejects-valid PR caused by Giovanni's patch to make ">>" > be treated as the end of a template argument, as an attempt at > better error-recovery. That did not work in the case that the ">>" > was actually legitimately interpreted as a shift operator. A > consequence is that one of the tests in g++.dg/template/error10.C > now issues marginally inferior error messages, but correctness > first. I have troubles understanding why we were handling this before correctly: template <int N> struct IntHolder { static const int value = N; }; const int N = 4; const int S = 4; template <int> struct ShareHolder { static const int value = IntHolder< N>>S >::value; }; Did you check this? It is not that we were stopping parsing expressions at the first ">>" we saw. I think the problem is related to the fact that we special-case the fact that a non-type template parameters is, by itself, a value argument. This is of course true, but those of integral or enumaration type can also be part of constant expressions. We were taking care of this by checking if "the next token ends a template argument", but this predicate does not have a empty intersection set with "next token is an operator which is part of a constant expression". In other words, applying this one-liner (after reverting your patchlet) seems to fix the problem (but it is untested). What do you think of this? Giovanni Bajo
Attachment:
patch-pr18140.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |