You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make overload pruning based on result types less aggressive (#21744)
`adaptByResult` was introduced in 2015 in
54835b6 as a last step in overloading
resolution:
> Take expected result type into account more often for overloading
resolution
>
> Previously, the expected result type of a FunProto type was ignored
and taken into
> account only in case of ambiguities. arrayclone-new.scala shows that
this is not enough.
> In a case like
>
> val x: Array[Byte] = Array(1, 2)
>
> we typed 1, 2 to be Int, so overloading resulution would give the
Array.apply of
> type (Int, Int*)Array[Int]. But that's a dead end, since Array[Int] is
not a subtype
> of Array[Byte].
>
> This commit proposes the following modified rule for overloading
resulution:
>
> A method alternative is applicable if ... (as before), and if its
result type
> is copmpatible with the expected type of the method application.
>
> The commit does not pre-select alternatives based on comparing with
the expected
> result type. I tried that but it slowed down typechecking by a factor
of at least 4.
> Instead, we proceed as usual, ignoring the result type except in case
of
> ambiguities, but check whether the result of overloading resolution
has a
> compatible result type. If that's not the case, we filter all
alternatives
> for result type compatibility and try again.
In i21410.scala this means we end up checking:
F[?U] <:< Int
(where ?U is unconstrained, because the check is done without looking at
the
argument types)
The problem is that the subtype check returning false does not mean that
there is no instantiation of `?U` that would make this check return
true, just that type inference was not able to come up with one. This
could happen for any number of reason but commonly will happen with
match types since inference cannot do much with them.
We cannot avoid this by taking the argument types into account, because
this logic was added precisely to handle cases where the argument types
mislead you because adaptation isn't taken into account. Instead, we can
approximate type variables in the result type to trade false negatives
for false positives which should be less problematic here.
Fixes#21410.
0 commit comments