Hi,
On 07/03/2018 21:23, Jason Merrill wrote:
On Wed, Mar 7, 2018 at 12:18 PM, Paolo Carlini <paolo.carl...@oracle.com> wrote:
Hi,
[snip the various clarifications]
Il 7 Marzo 2018 17:57:07 CET, Jason Merrill <ja...@redhat.com> ha scritto:
My thought was that this patch adds a lot of managing of the flag in
different places in the parser, whereas looking for error_mark_node in
the template parms here would be just in one place. But if you prefer
the current approach, that's fine, it's straightforward enough.
Thanks a lot for the various clarifications above, where essentially turns out
that some details of my patch are correct essentially by chance ;) Seriously,
I'm thinking the following: since 8 is getting real close, what if, for 8, for
the known mild regressions, we go ahead with my super safe Plan B which I
mentioned at beginning of the thread, then as soon as trunk branches we
immediately apply my patch and we give it a serious spin, say we rebuild
distros with it, and see what happens?
This is what I was suggesting, what do you think?
Eh, eh, certainly I don't have anything to say from the correctness
point of view. As I already tried to explain, what I find annoying in
this kind of approach, no matter how well is implemented, is that at
parsing time we have to go anyway over all the parameters of all the
template lists and then we know once and for all, for the corresponding
class, whether there are erroneous parameters or not. In this kind of
approach we go again through all the parameters, and, for example,
multiple times when there are nested classes for example, I'm pretty
sure in some (other) cases too (I should think more about that to be
more specific). If you ask my opinion, at the moment I still believe
that the best solution would be doing something at parsing time, save
the information, in a more elegant way, maybe adding a special
"erroneous TREE_VEC" flag to the TREE_VECs. I don't know exactly. Even
better a unique flag for all the template parameter lists of each class.
That said, if you don't foresee immediate performance-related issues,
it's of course your call ;) If/when I will have a more concrete
alternate proposal I will speak up ;) Nice anyway that we agree about
the basic idea :-)
Paolo.
