When simplifying match types, ensure fully defined before reducing #11980
Conversation
Fixes scala#11977 Previously the match types were more often fully defined because inlining at Typer caused more situations where type variables were instantiated. Now that inlining is done later, we need to compensate. I believe it's a good idea anyway since it means we can reduce more match types.
|
I put this under the 3.0 milestone since this we should discuss whether this fix requires a backport to the 3.0 RC branch (which means a new RC would be necessary). It certainly should be backported if we decide a new RC is necessary but I am not sure whether it is severe enough to require a new RC by itself. The issue it fixes is certainly annoying and embarrassing. Basic tuple operations failed with weird types. I am a bit surprised this was not caught earlier since the problems exist since RC1. On the other hand, it will affect new code only, and not be a problem for forward ported 2.13 code, since the failing operations are all 3.0 only. So, is that enough to go though another RC cycle for 3.0, or should we roll it into 3.0.1 which will come out 6 weeks after? |
Fixes #11977
Previously the match types were more often fully defined because inlining at Typer
caused more situations where type variables were instantiated. Now that inlining
is done later, we need to compensate. I believe it's a good idea anyway since it
means we can reduce more match types.
The weird widening from
InttoLongin #11977 happened because the original match type was unreduced, so the original expression was judged as non-conforming. So Typer searched for an implicit conversion. But every conversion forced the matchtype to be fully defined and therefore reducible, so every implicit conversion to a wider numeric type succeeded. Then the smallest target was chosen: i.e. Int -> Long, or Long -> Float.