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]

Re: C++ PATCH: PR c++/17435, c++/18140


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]