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.


Reply via email to