On 11/12/2014 10:27 AM, Andrew Sutton wrote:
Agreed. I'll probably start looking at this on Friday morning.
Note that end of stage 1 is Saturday, as I just realized today. So the
sooner the better. :)
deduce_concept_introduction (tree expr)
Do you still need this coerce_template_parms now that I've added a call to
lookup_template_variable? Well, once my change is merged onto the branch or
the branch onto trunk.
Maybe? I'm not sure what the call to lookup_template_variable is going
to do :) I think we still need to instantiate default arguments in
order to perform the match.
I meant that lookup_template_variable now calls coerce_template_parms
(on trunk), so you shouldn't need to do it again here.
I'm nervous about misusing these fields this way. Why is a constrained
parameter represented as a TYPE_DECL?
I think it was because the callers of cp_parser_nonclass_name (?)
expect to get back some kind of type or type-decl. This was the most
direct way to make constrained-type-specifiers and
constrained-parameters work (I did this at the meeting in Issaquah as
a proof of concept).
I don't especially like it either. Any recommendations?
Maybe another new tree code for constrained-type-specifier?
There are cases where trying to be proactive about diagnosing those
lookups broke a lot of existing parses, specifically the
postfix-expression for constructor calls. For example, in C(args), if
T finds
template<typename T>
concept bool C() { return true; }
template<typename T>
int C(int n) { return n; }
We to select C(int).
The check for introductions might be a special case.
Probably.
Jason
