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
Fix improper usage of constrained breaking type inference
In multiple places, we had code equivalent to the following pattern:
val (tl2, targs) = constrained(tl)
tl2.resultType <:< ...
which lead to subtype checks directly involving the TypeParamRefs of the
constrained type lambda. This commit uses the following pattern instead:
val (tl2, targs) = constrained(tl)
tl2.instantiate(targs.map(_.tpe)) <:< ...
which substitutes the TypeParamRefs by the corresponding TypeVars in the
constraint. This is necessary because when comparing
TypeParamRefs in isSubType:
- we only recurse on the bounds of the TypeParamRef using
`isSubTypeWhenFrozen` which prevents further constraints from being
added (see the added stm.scala test case for an example where this
matters).
- if the corresponding TypeVar is instantiated and the TyperState has
been gc()'ed, there is no way to find the instantiation corresponding
to the current TypeParamRef anymore.
There is one place where I left the old logic intact:
`TrackingTypeComparer#matchCase` because the match type caching
logic (in `MatchType#reduced`) conflicted with the use of TypeVars since
it retracts the current TyperState.
This change breaks a test which involves an unlikely combination of
implicit conversion, overloading and apply insertion. Given that there
is always a tension between type inference and implicit conversion, and
that we're discouraging uses of implicit conversions, I think that's an
acceptable trade-off.
0 commit comments