Scala 2.13 regression in for comprehension with wildcard syntax which mixes Unit and Nothing

[oxbowlakes]

Consider the following code:

Welcome to Scala 2.12.8 (OpenJDK 64-Bit Server VM, Java 1.8.0_181).
Type in expressions for evaluation. Or try :help.

scala> trait X[A] { def map[B](f: A => B): X[B]; def flatMap[B](f: A => X[B]): X[B] }
defined trait X

scala> lazy val void: X[Unit] = ???
void: X[Unit] = <lazy>

scala> lazy val unreachable: X[Nothing] = ???
unreachable: X[Nothing] = <lazy>

scala> lazy val x: X[Nothing] = for (_ <- void; u <- unreachable) yield u
x: X[Nothing] = <lazy>

Then if we use scala 2.13:

Welcome to Scala 2.13.0 (OpenJDK 64-Bit Server VM, Java 1.8.0_181).
Type in expressions for evaluation. Or try :help.

scala> trait X[A] { def map[B](f: A => B): X[B]; def flatMap[B](f: A => X[B]): X[B] }
defined trait X

scala> lazy val void: X[Unit] = ???
void: X[Unit] = <lazy>

scala> lazy val unreachable: X[Nothing] = ???
unreachable: X[Nothing] = <lazy>

scala> lazy val x: X[Nothing] = for (_ <- void; u <- unreachable) yield u
                                       ^
       error: type mismatch;
        found   : Unit => X[Nothing]
        required: Unit => X[B]

This can be "fixed" by assigning a non-underscore identifier to the Unit result of void. That is:

scala> lazy val x: X[Nothing] = for (v <- void; u <- unreachable) yield u
x: X[Nothing] = <lazy>

[SethTisue]

is it crucial that the for desugaring is involved, or does the desugared code show the same difference in behavior?

[oxbowlakes]

You'll have to excuse my desugaring know-how, but the following compiles on 2.13:

scala> lazy val x: X[Nothing] = void.flatMap(_ => unreachable.map(u => u))
x: X[Nothing] = <lazy>

[som-snytt]

The difference is that the underscore is now correctly treated as a pattern and not as a variable id named underscore.

The result is a different type arg inferred for the flatMap, which was flatMap[u.type forSome { val u: Nothing }] and is now flatMap[Nothing]. I don't know whether that is a bug or a feature, but it's clear that it "could" infer the existential from the single case, where the map does have that type arg.

Diff of -Xprint:parser,typer:

14c14,16
<     lazy val x: X[Nothing] = void.flatMap(((_) => unreachable.map(((u) => u))))
---
>     lazy val x: X[Nothing] = void.flatMap(((x$1) => x$1: @scala.unchecked match {
>       case _ => unreachable.map(((u) => u))
>     }))
31c38,40
<     <stable> <accessor> lazy val x: ufor.X[Nothing] = Test.this.void.flatMap[u.type forSome { val u: Nothing }](((_: Unit) => Test.this.unreachable.map[u.type forSome { val u: Nothing }](((u: Nothing) => u))))
---
>     <stable> <accessor> lazy val x: ufor.X[Nothing] = Test.this.void.flatMap[Nothing](((x$1: Unit) => (x$1: Unit @unchecked) match {
>       case _ => Test.this.unreachable.map[u.type forSome { val u: Nothing }](((u: Nothing) => u))
>     }))

For the same reason, the following works in 2.12 but not 2.13:

for (_ <- List(1,2,3)) yield `_` * 2

[SethTisue]

relevant: #7691 and other tickets that can be found by chasing links from there

[som-snytt]

Just to highlight, I didn't close because I wasn't sure if the type inference difference is actually a bug.

[SethTisue]

because I wasn't sure if the type inference difference is actually a bug

(me either, but I think that would be best served by a new, more focused ticket)