On Wed, Mar 7, 2018 at 10:55 AM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Hi, > > On 07/03/2018 16:38, Jason Merrill wrote: >> >> On Tue, Mar 6, 2018 at 5:00 PM, Paolo Carlini <paolo.carl...@oracle.com> >> wrote: >>> >>> On 06/03/2018 21:33, Jason Merrill wrote: >>>> >>>> Interesting, that seems like a promising idea. I'm not sure we need >>>> to do this based on an error in a default template arg, though; can we >>>> drop >>>> >>>> + || error_operand_p (TREE_PURPOSE (parameter))) >>>> >>>> ? >>> >>> Good point, yes, I believe we can, isn't necessary for all the snippets I >>> have around neither apparently to pass the testsuite (but this is rather >>> straightforward, right?). As I said, I tried many different things, some >>> also fiddled with TREE_PURPOSE, in pt.c too, but in what I sent I only >>> added >>> the check out of a reflex. Anyway, the below is in libstdc++, so far so >>> good. >> >> What if, instead of adding another flag to cp_parser, we look for >> errors in the template parms for a particular member before we do any >> late parsing for it? > > Thus do the check before: > > FOR_EACH_VEC_SAFE_ELT (unparsed_funs_with_definitions, ix, decl) > cp_parser_late_parsing_for_member (parser, decl); > > and therefore skip the whole set of unparsed_funs? Because the template > parameters to be considered is the same for all of them, right?
No; member templates have more template parameters; the error might be in a nested class, and not affect functions from an enclosing class. > (otherwise something is seriously wrong with my very idea!) Not that seriously; once we've seen an error all bets are off, and we're free to decide that enclosing class functions aren't worth parsing in that case, either. > And what about the other > entities in the 'else if (--parser->num_classes_being_defined == 0)' body? They also have associated decls where we can look at template parameters. > On one hand I'm certainly concerned that we may be too heavy handed, on the > other hand we may risk inconsistencies, with some definitions available > during error recovery other not, where all of them have broken outer > template parameters anyway. Well, in general, I must say that - assuming the > possibly erroneous template parameters are shared by all the entities in the > 'else if (--parser->num_classes_being_define == 0)' body - it would be too > bad going through again all the template parameters where with just a bool > we could save the work that we already did anyway, if see what I mean... 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. Jason
