Align erasure of Array[Nothing] and Array[Null] with Scala 2

[hamzaremmal]

Closes #22515

[smarter]

Instead of doing a new scripted test, can you include the test code in https://github.com/scala/scala3/tree/main/sbt-test/scala2-compat/erasure ?

[smarter]

(also the test could include Array[? <: Nothing] and Array[? <: Null])

[hamzaremmal]

This should actually be:

Suggested change

	def objectARRAY_93(x: Array[_ <: Nothing]): Unit = {}
	def objectARRAY_94(x: Array[_ <: Null]): Unit = {}
	def nothing$ARRAY_93(x: Array[_ <: Nothing]): Unit = {}
	def null$ARRAY_94(x: Array[_ <: Null]): Unit = {}

but for some reason, it passes the test locally, I will have to test it better, but my machine keeps crashing... so checking with the CI :)

[hamzaremmal]

So this is weird, the CI passes while Array[_ <: Nothing] erasure is wrong. I've tested with the following:

// In Scala 2
class Foo {
    def a: Array[Nothing] = null
    def b: Array[Null] = null
    def c: Array[_ <: Nothing] = null
    def s: Array[_ <: Null] = null
}

// In Scala 3
@main def Test =
    (new Foo).a
    (new Foo).b
    (new Foo).c
    (new Foo).s

The generated bytecode from Scala 2 is the following:

Compiled from "s2.scala"
public class Foo {
  public java.lang.Object[] a();
  public java.lang.Object[] b();
  public scala.runtime.Nothing$[] c();
  public scala.runtime.Null$[] s();
  public Foo();
}

We can clearly see Scala 3 (this PR) emitting a call to the wrong method for Foo.c:

public final class s3$package$ implements java.io.Serializable {
  public static final s3$package$ MODULE$;

  public static {};
    Code:
       0: new           #2                  // class s3$package$
       3: dup
       4: invokespecial #16                 // Method "<init>":()V
       7: putstatic     #18                 // Field MODULE$:Ls3$package$;
      10: return

  public scala.runtime.Null$[] Test();
    Code:
       0: new           #29                 // class Foo
       3: dup
       4: invokespecial #30                 // Method Foo."<init>":()V
       7: invokevirtual #34                 // Method Foo.a:()[Ljava/lang/Object;
      10: pop
      11: new           #29                 // class Foo
      14: dup
      15: invokespecial #30                 // Method Foo."<init>":()V
      18: invokevirtual #37                 // Method Foo.b:()[Ljava/lang/Object;
      21: pop
      22: new           #29                 // class Foo
      25: dup
      26: invokespecial #30                 // Method Foo."<init>":()V
      29: invokevirtual #40                 // Method Foo.c:()Ljava/lang/Object;
      32: pop
      33: new           #29                 // class Foo
      36: dup
      37: invokespecial #30                 // Method Foo."<init>":()V
      40: invokevirtual #43                 // Method Foo.s:()[Lscala/runtime/Null$;
      43: areturn
}

[hamzaremmal]

I've checked a bit and throwing a LinkageError will not be considered a failure... but the problem is that there is a linkage error before the code I've added (I still need to find which one).

[hamzaremmal]

There is already an issue opened on sbt (sbt/sbt#6852). The proposed workaround (fork := true) worked locally

[hamzaremmal]

TODO: Inspect why both these methods' erasures are wrong, or why were they considered correct.

[hamzaremmal]

I've extracted this to its issue (#22525). I would like to merge this one so I can make progress in #22480 @smarter @sjrd, is that okay with you?

[hamzaremmal]

Workaround until #22524 is resolved

[hamzaremmal]

I forgot it was approved... I have the reflex to enable auto-merge when I'm done with a PR (Sorry...)

[smarter]

No worries, seems fine to me as is.

[tgodzik]

I think this should require minor @hamzaremmal ? Just for the sake of backporting to LTS since we are at 3.7.0 anyway

[sjrd]

Not necessarily. It's a bug fix to be able to call certain Scala 2 methods that would previously throw AbstractMethodErrors.

[hamzaremmal]

It's a bug fix, it shouldn't require a minor release

[tgodzik]

That's what I thought, but wanted to be sure. Thanks!