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:

[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 :-)


Reply via email to