On Thu, Dec 24, 2015 at 9:41 PM, Jason Merrill <ja...@redhat.com> wrote:
> On 12/24/2015 12:57 PM, Patrick Palka wrote:
>>
>> So instead, this patch
>> takes the easier route and just adds preparatory logic to decay these
>> dependent array parameter types where necessary so that by the time
>> unify() is called it will be looking at two decayed T * types.  There
>> only seem to be three places where this needs to be done.
>
>
> Does it not make sense to do this in maybe_adjust_types_for_deduction?

That alone would not be sufficient because more_specialized_fn()
doesn't call maybe_adjust_types_for_deduction() beforehand, yet we
have to do the decaying there too (and on both types, not just one of
them).

And maybe_adjust_types_for_deduction() seems to operate on the
presumption that one type is the parameter type and one is the
argument type. But in more_specialized_fn() and in get_bindings() we
are really working with two parameter types and have to decay them
both. So sometimes we have to decay one of the types that are
eventually going to get passed to unify(), and other times we want to
decay both types that are going to get passed to unify().
maybe_adjust_types_for_deduction() seems to only expect the former
case.

Finally, maybe_adjust_types_for_deduction() is not called when
unifying a nested function declarator (because it is guarded by the
subr flag in unify_one_argument), so doing it there we would also
regress in the following test case:

void foo (int *);

template <typename T>
void bar (void (T[5]));

void
baz (void)
{
  bar (foo); // type of function foo will no longer unify with void
(T[5]) so deduction of type T now fails
}

Reply via email to