On Wed, Mar 7, 2018 at 10:55 AM, Paolo Carlini <paolo.carl...@oracle.com> wrote:
> On 07/03/2018 16:38, Jason Merrill wrote:
>> On Tue, Mar 6, 2018 at 5:00 PM, Paolo Carlini <paolo.carl...@oracle.com>
>>> 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
>>>> + || 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
>>> the check out of a reflex. Anyway, the below is in libstdc++, so far so
>> 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.