This is the mail archive of the
mailing list for the GCC project.
Re: [c++-concepts] requires expressions
- From: Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Gabriel Dos Reis <gdr at axiomatics dot org>
- Date: Sat, 13 Jul 2013 07:37:46 -0500
- Subject: Re: [c++-concepts] requires expressions
- References: <CANq5SyuTAkpLtqdcCAjFko_L5JwMm+4imOj+cdxEgbs5pRvY8A at mail dot gmail dot com> <51E0573A dot 2040809 at redhat dot com>
> This should be merged with pp_cxx_parameter_declaration_clause.
>> +reqparms_to_string (tree p)
> And this should have a more generic name.
I called this parms_to_string for symmetry with args_to_string. It
>> + if (check_requirements (t, args))
>> + return;
>> + ++processing_template_decl;
>> + tree subst = instantiate_requirements (t, args);
>> + --processing_template_decl;
> Surely you need to instantiate before checking, here and elsewhere.
check_requirements will instantiate before evaluating.
There are two instantiations on purpose. If checking succeeds, then
there are no failures in this branch of constraint, so we don't need
to recursively diagnose failures.
The second generates a possibly invalid tree that is useful for
emitting precise diagnostics, written in terms of the template
arguments. Basically, it means I can generate this message:
'int::type' is not a valid type name.
for failed nested type requirements.
>> + inform (loc, " %qE is not valid syntax", TREE_OPERAND (t, 0));
> I don't think I would mention "syntax" here, since a syntax error would have
> been diagnosed at parse time rather than constraint checking time.
"is not a valid expression" seems more appropriate.
>> +// In an unevaluated context, the substitution of parm decls are not
>> +// properly chained during substitution. Do that here.
>> +static tree
>> +fix_local_parms (tree sparms)
> A lot of the new code in pt.c doesn't seem like it needs to be there; let's
> put as much in constraint.cc as we can. Let's move some of the bits out of
> semantics.c as well.
I think the [fixup|declare]_local_parms could move to semantics.c.
Would you recommend moving tsubst_* for requirements into