Static forwarders are sometimes missing generic signatures

[lrytz]

There's a regression from 2.12.7 to 2.12.8, but also some older inconsistency.

Source file:

trait A[T] {
  type U
  def foo(t: T): List[String] = Nil
  def bar(u: U): List[String] = Nil
}
object O extends A[String] { type U = String }

2.12.7

When compiled with 2.12.7, we get signatures for the default methods in A.class:

  // signature (TT;)Lscala/collection/immutable/List<Ljava/lang/String;>;
  public default foo(Ljava/lang/Object;)Lscala/collection/immutable/List;

  // access flags 0x1
  // signature (Ljava/lang/Object;)Lscala/collection/immutable/List<Ljava/lang/String;>;
  public default bar(Ljava/lang/Object;)Lscala/collection/immutable/List;

The signature of foo refers to A's type parameter T. in the signature of bar, the type member U is erased to Object.

Looking at the mixin methods in the module class O$, we see that O$.bar has a signature (the same as A.bar), but O$.foo doesn't have any. Not sure if that's by design, or if that's a bug. Simply using the same signature as A.foo would be wrong, as the O$ class doesn't have a type parameter T.

Looking at the static forwarders in O, O.bar has a signature, O.foo doesn't.

Abstract Class

If we change A to be an abstract class, the signatures for A.foo and A.bar are the same as before. O$ no longer has mixins. The static forwarders in O are both without signature. I assume that's a bug? O.bar could have the same signature as A.bar.

2.12.8

When compiling the original source (trait A) with 2.12.8, there's a difference: the static forwarder O.bar is now also without signature. This is the regression compared to 2.12.7.

Other than that, 2.12.8 produces the same methods/signatures as 2.12.7 (also if A is an abstract class).

[lrytz]

What happens

• before 2.12.8, we selected the members to emit static forwarders at JVM phase, now we select them exitingUncurry ((https://github.com/scala/scala/pull/7469/files#diff-7a3aa9d1c9acd44da15dc536d4760e5aL898)).
• This means we're before mixin, and we get A.foo instead of the mixin forwarder O.foo
• This changes the result of staticForwarderGenericSignature. The erasedMemberType computed in this method for O.foo is (Object)List, while the for A.foo it's (String)List. The .info (during JVM phase) gives (Object)List in both cases.
• So the signature is dropped because the types don't match.

There's a really long list of issues related to generic signatures. The workaround in staticForwarderGenericSignature to drop signatures is not very precise, but just looking at past discussions it seems really difficult to get this right (#3452).

I'm not sure what would be a good way to improve on this in 2.12.x.

As a workaround, one can manually override the methods in the object O. Then the compiler will generate the generic signatures for both O.foo and O.bar.

trait A[T] {
  type U
  def foo(t: T): List[String] = Nil
  def bar(u: U): List[String] = Nil
}
object O extends A[String] {
  type U = String
  override def foo(t: String): List[String] = super.foo(t)
  override def bar(u: String): List[String] = super.bar(u)
}

[lrytz]

We could add make the compiler emit a warning when it drops the generic signature for a static forwarder, possibly under -Xlint

[2m]

Just a FYI, the Alpakka Ftp connector that we noticed this regression originally in does not compile with Scala 2.13.0-M5 with the same errors.

[SethTisue]

Just a FYI, the Alpakka Ftp connector that we noticed this regression originally in does not compile with Scala 2.13.0-M5 with the same errors.

is that just because scala/scala#7469 didn't land until after 2.13.0-M5 was released?

[ennru]

We have this issue with Scala 2.13 in Alpakka FTP, but as far as I can see there is no fix for it, yet (not in 2.12.9 nor 2.13.0).

[eed3si9n]

See also https://twitter.com/not_xuwei_k/status/1149047269766959104 by @xuwei-k

after bumping to Mima 0.4.0, I'm getting incompats on slightly older projects like Scala 2.12.7 (but not on 2.11 or 2.10), so I suspected the bridge method @eed3si9n was messing with in scala/scala#7035 … but it also happens in 2.12.6, so not sure

[ennru]

I assume a fix for this won't be part of 2.13.1, either. Right @lrytz ?

[lrytz]

I'm not planning to work on this in the near future, I'm afraid..