[Regression in 3.1.2-RC1] Inferred union in type argument position gets widened #14494
Comments
ansvonwa
added
itype:bug
stat:needs triage
romanowski
added
the
regression
romanowski
added
area:implicits
|
It would be good to identify the commit that caused this. |
|
In 3.1.1 the following code used to infer a result type of object ImplNotFound:
def main(args: Array[String]): Unit =
val res = (??? : Seq[Int]).collect {
case 1 => Seq("")
case 2 => Seq(1)
}[[syntax trees at end of typer]] // try/i14494.scala
package <empty> {
final lazy module val ImplNotFound: ImplNotFound = new ImplNotFound()
final module class ImplNotFound() extends Object() {
this: ImplNotFound.type =>
def main(args: Array[String]): Unit =
{
val res: Seq[Seq[String | Int]] =
(??? :Seq[Int]).collect[Seq[String | Int]](
{
def $anonfun(x$1: Int): Seq[String | Int] =
x$1:(x$1 : Int) @unchecked match
{
case 1 =>
Seq.apply[String](["" : String]*)
case 2 =>
Seq.apply[Int]([1 : Int]*)
}
closure($anonfun:PartialFunction[Int, Seq[String | Int]])
}
)
()
}
}
}But now the union gets widened to Matchable: package <empty> {
final lazy module val ImplNotFound: ImplNotFound = new ImplNotFound()
final module class ImplNotFound() extends Object() {
this: ImplNotFound.type =>
def main(args: Array[String]): Unit =
{
val res: Seq[Seq[Matchable]] =
(??? :Seq[Int]).collect[Seq[Matchable]](
{
def $anonfun(x$1: Int): Seq[Matchable] =
x$1:(x$1 : Int) @unchecked match
{
case 1 =>
Seq.apply[String](["" : String]*)
case 2 =>
Seq.apply[Int]([1 : Int]*)
}
closure($anonfun:PartialFunction[Int, Seq[Matchable]])
}
)
()
}
}No idea why. |
|
I don't believe I'll have time to fix this for 3.1.2 (or any time before September of this year really!) |
|
I guess the root of the problem is that type variable avoidance and widenUnion do not commute, as widenUnion is happy to widen any union it sees at the top-level when instantiating a type variable, and adding more type variables create more opportunity for it to run. Perhaps we can simply not run widenUnion when instantiating a type variable created by avoidance (which can be identified by checking for AvoidNameKind on its name) |
|
In fact, it's not even that we have more type variables which causes issues, it's that we're instantiating them in a different order, given: ?A1 >: String
?A2 >: Int
?B >: Seq[?A1] | Seq[?A2]If we instantiate ?A1 and ?A2 first we're left with ?B := Seq[?A1]
?A1 >: String | IntAnd then of course we instantiate to |
This seems hard to track of. Perhaps we need to rethink widening on type variable instantiation. Can we get away with only widening soft unions when inferring the type of a definition and when performing an implicit search? |
smarter
changed the title
|
/cc @mbovel who's been on a crusade for less widening :) |
|
Alternative idea: when we add the constraint |
|
@smarter Would it be possible to get the wip into 3.1.3? We are sort of blocked on this regression. |
|
I'm not confident in what that wip is doing, I have no idea if it's sound and it might break as many things as it fixes. I'm more optimistic on the plan I outlined in #14770 (comment) which would make the logic that creates hard unions in constraints more robust in general. |
|
Hmm. Should we revert #14026 then? |
|
Possibly, though instead of reverting everything you probably only need to revert 3ab18a9 and the subsequent commits that removed workarounds that were no longer needed after that commit. Instead of reverting it might also be easier to turn off level-checking (make levelOK always return true) |
OK, I am going to try that. |
|
Unfortunately, this fails the bootstrap build. I get Any advice what we should do here? |
Compiler version
3.1.2-RC1First bad commit 3ab18a9 in #14026
Minimized code
Output
Expectation
Successful compilation as in
3.0.0to3.1.1The text was updated successfully, but these errors were encountered: