is not a trait error when extends Java annotation
#12840
Labels
Milestone
Comments
xuwei-k
changed the title
is not a trait error when extends Java annotation
|
|
|
It's most likely a problem in JavaParser. |
|
We intentionally pretend that Java annotations are classes, this is done to make them closer to Scala annotations and avoid special-casing, but it does mean that things can go wrong sometimes. Scala 2 used to do the same but switched to representing them as traits a while ago (#5690 (comment) has the history) which carries its own set of challenges, and even if we changed our representation now, we'd still need to support the old representation coming from tasty files compiled with scala 3.0. In brief, it's a mess. |
|
another example build.sbtlibraryDependencies += "com.typesafe.play" %% "play" % "2.8.8" cross CrossVersion.for3Use2_13
scalaVersion := "3.0.1"Main.scalaobject Main {
new play.inject.NamedImpl("")
}log |
|
We are also running into this issue when trying to cross-build twitter/util's util-reflect. An example is the Widget and it's implementation. We get the same error: This is running with scala 3.0.2-RC1. |
This was referenced Jun 3, 2022
8 tasks
smarter
added a commit
to dotty-staging/dotty
that referenced
this issue
Oct 28, 2022
Previously we treated Java annotations as if they were classes, like Scala
annotations. For example, given
@interface Ann { int foo(); }
we pretended it was defined as:
abstract class Ann(foo: Int) extends java.lang.annotation.Annotation { def foo(): Int }
We take advantage of this to type annotation trees as if they were
new calls, for example `@Ann(1)` is typed as `new Ann(1)`.
Pretending that annotations are classes is fine most of the time and matches
what Scala 2.12 did, but it's problematic because the JVM treats annotations as
interfaces. In practice this was only an issue with code trying to extend
Java annotations, which would either be rejected at compile-time or miscompiled
before this commit.
This commit switches our representation of annotations to be trait-based
instead:
trait Ann(foo: Int) extends java.lang.annotation.Annotation { def foo(): Int }
Classes are then free to extend annotations using the same pattern as in Scala 2.13:
class Foo extends Ann {val annotationType = classOf[Retention]; def foo(): Int = 1}
Notice that we still pretend these traits have constructors, this lets us type
annotation trees in much the same way as before, and crucially it means that
macros that depended on the exact tree shape of annotation trees can continue to
work, as demonstrated by the annot-java-tree test extracted from wartremover.
To prevent miscompilation issues, we disallow passing arguments to the
annotation constructor in `extends` clause.
The treatment of default arguments to annotations stays unchanged from 85cd1cf.
Fixes scala#5690. Fixes scala#12840. Fixes scala#14199.
little-inferno
pushed a commit
to little-inferno/dotty
that referenced
this issue
Jan 25, 2023
Previously we treated Java annotations as if they were classes, like Scala
annotations. For example, given
@interface Ann { int foo(); }
we pretended it was defined as:
abstract class Ann(foo: Int) extends java.lang.annotation.Annotation { def foo(): Int }
We take advantage of this to type annotation trees as if they were
new calls, for example `@Ann(1)` is typed as `new Ann(1)`.
Pretending that annotations are classes is fine most of the time and matches
what Scala 2.12 did, but it's problematic because the JVM treats annotations as
interfaces. In practice this was only an issue with code trying to extend
Java annotations, which would either be rejected at compile-time or miscompiled
before this commit.
This commit switches our representation of annotations to be trait-based
instead:
trait Ann(foo: Int) extends java.lang.annotation.Annotation { def foo(): Int }
Classes are then free to extend annotations using the same pattern as in Scala 2.13:
class Foo extends Ann {val annotationType = classOf[Retention]; def foo(): Int = 1}
Notice that we still pretend these traits have constructors, this lets us type
annotation trees in much the same way as before, and crucially it means that
macros that depended on the exact tree shape of annotation trees can continue to
work, as demonstrated by the annot-java-tree test extracted from wartremover.
To prevent miscompilation issues, we disallow passing arguments to the
annotation constructor in `extends` clause.
This change is not fully backwards source compatible: this is illustrated
by the diffs in tests/run/repeatable/Test_1.scala:
-@FirstLevel_0(Array(Plain_0(4), Plain_0(5)))
+@FirstLevel_0(Array(new Plain_0(4), new Plain_0(5)))
Here, FirstLevel_0 takes an array of `Plain_0` annotations as arguments, and in
previous releases of Scala 3 we could put `Plain_0(4)` in this array without
`new`. This is because the compiler generates a "constructor proxy" apply method
for classes, but this no longer works since `Plain_0` is now a trait. While we
could potentially tweak the constructor proxy logic to handle this case, it
seems simpler to require a `new` here, both because Scala 2 does it too and
because it ensures that user code that inspects the annotation tree does not
have to deal with constructor proxies.
The treatment of default arguments to annotations stays unchanged from 85cd1cf.
Fixes scala#5690. Fixes scala#12840. Fixes scala#14199.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiler version
3.0.1-RC1,3.0.2-RC1-bin-20210615-a8bbc0e-NIGHTLYMinimized code
A.scala
Named.java
Output
Expectation
compile success because
javac Named.javasuccess.Note
Could not build playframework due to this issue.
https://github.com/playframework/playframework/blob/d1f59e95892c69b1bd7e03d63997bb8c54a8de8a/core/play/src/main/java/play/inject/NamedImpl.java#L7-L17
The text was updated successfully, but these errors were encountered: