Annotations and java seq

[DarkDimius]

That's not proposed for merging yet, as it triggered other bugs.

@odersky can you please have a look on commits starting from b15bd30?
Changes to typer also made typer not able to retype itself. It fails with a datarace: https://gist.github.com/DarkDimius/d2b5b5cb34e7c400c741 This seems to be unrelated with changes that were made, just triggered by additional code.

I'm not investigating the CyclicReferenceError's that are triggered during Erasure.

[DarkDimius]

@odersky please review.
This should be enough to fix annotations and <repeated> related errors so @olhotak could proceed with java parser

[olhotak]

I haven't had a chance to look into it in depth yet, but this PR does not fix any of the three failing tests in #183, and causes an additional test failure.

[olhotak]

Here is a Scala-only program that causes the same assertion failure in FirstTransform as the t1782 Java-interop test.

class Annot(value: Int) extends scala.annotation.Annotation
@Annot(value = 42) class Test

The other two failures (t294 and t1751) are more complicated, but also involve trees in annotations, so hopefully the same fix will also fix them.

The new failure appears to be caused by elimRepeated (incorrectly) transforming the parameter type of the Java varargs bridge. There is a Java varargs method overridden by a Scala varargs method. For the Scala varargs method, the parameter type after elimrepeated is a Seq. In order to override the Java varargs method, a bridge is added to the Scala class with a parameter type of Array. This works correctly without this PR. But with this PR, the parameter type of the varargs bridge somehow gets (incorrectly) changed from Array to Seq. But there is a call to the method passing an argument of type Array, which results in an assertion failure in TreeChecker.adapt.

[odersky]

Otherwise LGTM

[odersky]

I propose to get this in now. When it is in I'll see what I can do to generalize overloading resolution, disentangling it from typer.

[DarkDimius]

@odersky this is not the final version of overload resolution that I'm using now.
The currenly final is here: dotty-staging@6f1ade0
I guess it's already pretty reusable from next phases, could you have a look? It's part of #213 that is still in progress due to dirty hacks needed to read badly-typed annotation trees from bytecode.