MIMA Binary compatibility breakage updating `export` of `val` from Scala 3.7.4 -> 3.8.0-RC1

[lihaoyi]

Compiler version

3.8.0-RC1

Minimized code

package foo
object Foo{
  val hello = 1337
  def main(args: Array[String]): Unit = println(hello)
}

export Foo.*

Output

If you compile this code with 3.7.4 and 3.8.0-RC1 and run https://github.com/lightbend-labs/mima over the two jars, you get the following breakage report

Found 2 issue when checking against old
 * static method hello()Int in class foo.Foo#package has a different generic signature in current version, where it is ()Lscala/Function0<Ljava/lang/Object;>; rather than ()I. See https://github.com/lightbend-labs/mima#incompatiblesignatureproblem
   filter with: ProblemFilter.exclude[IncompatibleSignatureProblem]("foo.Foo#package.hello")
 * method hello()Int in object foo.Foo#package has a different generic signature in current version, where it is ()Lscala/Function0<Ljava/lang/Object;>; rather than ()I. See https://github.com/lightbend-labs/mima#incompatiblesignatureproblem
   filter with: ProblemFilter.exclude[IncompatibleSignatureProblem]("foo.Foo#package.hello")

Repro Zip:

test 2.zip

Unpack and run ./mill mimaReportBinaryIssues

Expectation

I would expect upgrading a library from Scala 3.7.4 to Scala 3.8.0-RC1 would not cause any binary compatibility breakage, so that downstream code that was previously compiled against the 3.7.4 version of the project would not hit issues compiling against the 3.8.0-RC1 version of the project

TBH I'm not sure if this MIMA-reported error is a real error or if it is a false positive. If it is a false positive, feel free to close the issue and we can add a MIMA filter to turn off this reporting. But squinting at the error message, it seems Scala 3.8.0 is messing up the generic signature somehow, reporting it as ()Lscala/Function0<Ljava/lang/Object;>; when it should be ()I

I hit this when trying to update Mill to 3.8.0-RC1 com-lihaoyi/mill#6242

[sjrd]

The new signature seems wrong indeed.

[hamzaremmal]

I can confirm that this is also visible in the bytecode:

hamzaremmal@macbook foo % javap test\$package
Warning: File ./test$package.class does not contain class test$package
Compiled from "test.scala"
public final class foo.test$package {
  public static scala.Function0<java.lang.Object> hello();
  public static void main(java.lang.String[]);
}
hamzaremmal@macbook foo % javap test\$package\$
Warning: File ./test$package$.class does not contain class test$package$
Compiled from "test.scala"
public final class foo.test$package$ implements java.io.Serializable {
  public static final foo.test$package$ MODULE$;
  public static {};
  public final scala.Function0<java.lang.Object> hello();
  public final void main(java.lang.String[]);
}

[hamzaremmal]

The regression was introduced by a mix of #24288 and #21890.
In the analysis of the issue, I discovered that we recover the generic type of exported member from the mixinForwarderGenericInfos. In the phase where it is recovered, we get the following type => (foo.Foo.hello : => Int).
Now, I understand why we have the first arrow since the exported member is represented as a parameterless method, but why we have a singleton type that refers to a parameterless function??!! Also, this representation seems to be the same in 3.7.4.

@sjrd do we agree that such a type => (foo.Foo.hello : => Int) makes no sense?

[hamzaremmal]

An even smaller reproducer:

val hello = 1337
val x: hello.type = ???

We generate the following code:

Compiled from "test.scala"
public final class test$package$ implements java.io.Serializable {
  public static final test$package$ MODULE$;
  public static {};
  public int hello();
  public scala.Function0<java.lang.Object> x();
}