Generic signature for wildcards changed in 2.13.7

[lrytz]

trait T[+X] { def x: X }
class C {
  type TT[+X] = T[X]
  def it(): TT[_] = new TT[String] { def x = "" }
}

diff --git a/C.class.asm b/C.class.asm
index c25e4e0..eeced80 100644
--- a/C.class.asm
+++ b/C.class.asm
@@ -14,8 +14,8 @@
     MAXLOCALS = 1

   // access flags 0x1
-  // signature ()LT<*>;
-  // declaration: T<?> it()
+  // signature ()LT<Ljava/lang/Object;>;
+  // declaration: T<java.lang.Object> it()
   public it()LT;
     NEW C$$anon$1
     DUP

The regression shows only when using the type alias. Discovered by @octonato and MiMa on Akka.

Not sure if that has any impact on Java clients. The following Java code works, no matter if the Scala code was compiled with 2.12.6 or 2.12.7:

public class A {
  public static void main(String[] args) {
    C c = new C();
    T<?> t = c.it();
    System.out.println(t.x());
  }
}

[dwijnand]

The regression shows only when using the type alias.

I almost felt like Object is right, seeing as TT is covariant and declaration-side variance isn't representable in Java. But it's T<?> and ()LT<*>; when not using the type alias, so it's at least inconsistent. But then Object is the top type of any type, so you're not gaining anything over ?.

Which lead me to compare what it looks like with another upper bound:

class Foo
trait T[+X <: Foo] { def x: X }
class C {
  type TT[+X <: Foo] = T[X]
  def it(): TT[_] = new TT[Foo] { def x = new Foo }
}

And that also emits Object over ?. So it's not doing anything more useful.

That is because I assumed TT[_] <:< TT[Foo], but it looks like it's not?

$ bat -p A.scala
object A {
  def main(args: Array[String]): Unit = {
    val c: C = new C()
    val t: T[Foo] = c.it()
    println(t.x)
  }
}
$ scalac -2.13.7 -cp . A.scala
A.scala:4: error: type mismatch;
 found   : T[Any]
 required: T[Foo]
    val t: T[Foo] = c.it()
                        ^
1 error

Confused... 🤯

[lrytz]

Bisected to scala/scala#9693

[lrytz]

Uncurry's expandAlias calls normalize, which calls ExistentialType.rewrap, which calls existentialAbstraction, which eliminates simple covariant existentials (see scala/scala#9693 (comment)). I guess this is because T[_] and T[Any] are equivalent for a covariant T. Is that also true when looking at T<?> vs T<Object> from Java's type system? cc @joroKr21.

[joroKr21]

Yes I already suspected as much but didn't have time to look at it yet. It's unfortunate that Scala doesn't dealias when computing the erasure (and bytecode signature). It leads to this kind of problems all the time 😬

[lrytz]

unfortunate that Scala doesn't dealias when computing the erasure (and bytecode signature)

can you elaborate? uncurry should remove type aliases, and it's before erasure. there are no type aliases in the bytecode involved here, not in the method signatures, nor in their generic signatures.

[joroKr21]

Oh sorry I think I confused an old PR of mine but it was specific to higher-kinded types: scala/scala#8720

[joroKr21]

I guess this is because T[_] and T[Any] are equivalent for a covariant T.

That's right

Is that also true when looking at T<?> vs T from Java's type system?

I don't know to be honest

[dwijnand]

That is because I assumed TT[_] <:< TT[Foo], but it looks like it's not?

Given type TT[+X <: Foo], and ideas why TT[_] <:< TT[Foo] fails?

[joroKr21]

In TT[_] the _ (which is an existential quantifier) does not inherit the bounds of the underlying type parameter.
That's one of the reasons why we skip existential skolems in ref checks. If that could be fixed, we wouldn't have to.
typeOf[TT[_ <: Foo]] <:< typeOf[TT[Foo]] is true for example.

I already tried to add those bounds to wildcards but I think it breaks down for F-bounded type parameters and for inferred existential types. Perhaps worth another try 🤔 - but if that subtype relationship were true, it doesn't fix the OP does it?

[lrytz]

Given type TT[+X <: Foo], and ideas why TT[_] <:< TT[Foo] fails?

If I understand the spec correctly, TT[_] is TT[t] forSome { t >: Nothing <: Any} no matter how TT is defined.

[lrytz]

Scala 3 only has wildcards, no existentials, so it handles this differently it seems:

scala> trait T[+X <: String]
scala> val t: T[String] = (null: T[_])
val t: T[String] = null