Fix #7212: Generate bridge for varargs annotation

[TheElectronWill]

This shares most of the logic with the generation of bridges for overrides of java varargs methods.

I've added tests in pos-java-interop, but I'm not 100% confident that this is the right place 🤔 moved to run/tests/i7212 after smarter's review

[smarter]

If you grep for @varargs in https://github.com/scala/scala/tree/2.13.x/test you'll find a bunch of tests, can you try to port them over and see if they work with your implementation? One thing which probably still needs to be handled is when a scala method without @varargs overrides a scala method with @varargs, in that case we still need to generate the varargs bridge for the override I think.

[smarter]

you'll find a bunch of tests

Note that tests in test/files/jvm in scalac are just run tests and can go in tests/run in dotty.

[TheElectronWill]

can you try to port them over and see if they work with your implementation?

I'll try that!

[TheElectronWill]

I've ported some tests but this one fails because the generic signatures aren't properly generated.
If the vararg uses a type parameter it doesn't show up in the signature, i.e. the backend emits [Ljava/lang/Object; instead of something like [TE;. It may not be in the scope of this PR.

[smarter]

If the vararg uses a type parameter it doesn't show up in the signature

This TODO is probably related: https://github.com/lampepfl/dotty/blob/ffd6a5892740d8038e85e0302d56591241135652/compiler/src/dotty/tools/dotc/transform/GenericSignatures.scala#L258
The corresponding code in scalac is: https://github.com/scala/scala/blob/9208bc449990cb9248837c3c841f651c121a4b66/src/compiler/scala/tools/nsc/transform/Erasure.scala#L378-L386
scalac relies on an attachement to remember the type parameter name, that's not very nice. Hopefully we don't need to do that in dotty because the varargs parameter has type Array[T & AnyRef] so the T is still present?

[TheElectronWill]

Yes the T is there (+1 for dotty :) ). I believe varargs are Array[? <: T & AnyRef] now.

I've just tried this test and it fails under -Ycheck:all with java.lang.AssertionError: assertion failed: Types differ while trying to compare T* and Seq[T]. Varargs + currying produce the same error:

object VarArgs {
  @annotation.varargs
  def two(a: Int)(b: String*): Nothing = ???
}

*** error while checking tests/pos/varargs-currying.scala after phase refchecks ***
exception occurred while compiling tests/pos/varargs-currying.scala
java.lang.AssertionError: assertion failed: Types differ
Original type : (b: String*): Nothing
After checking: (b: Seq[String]): Nothing
Original tree : VarArgs.two(a)
After checking: VarArgs.two(a)

I have yet to find the root cause of this.

[TheElectronWill]

The ported tests seem to work now. I've added some cases.

sconfig fails to build because it defines a @varargs-annotated method and then overrides it with a repeatable parameter and defines a conflicting method with an array parameter (as a workaround for the previous lack of @varargs handling). An error is expected. What should we do then? Remove (temporarily) sconfig from the community build?

[smarter]

What should we do then? Remove (temporarily) sconfig from the community build?

No need hopefully: all the projects in our community build are submodules in https://github.com/dotty-staging, so we can fix them without waiting on upstream. I've just given you access to that organization, so you should be able to push a new branch to github.com/dotty-staging/scodec/ with the fix in, and update this PR to make the scodec submodule point to that commit.

[TheElectronWill]

No need hopefully: all the projects in our community build are submodules in https://github.com/dotty-staging, so we can fix them without waiting on upstream. I've just given you access to that organization, so you should be able to push a new branch to github.com/dotty-staging/scodec/ with the fix in, and update this PR to make the scodec submodule point to that commit.

Done! SConfig was the only submodule not in dotty-staging so I forked it.

[TheElectronWill]

rebased

[smarter]

Awesome work, thanks! That was harder than I thought it would be :).

[smarter]

Otherwise LGTM!