-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix AnnotationInfo when using named/default arguments, support custom annotation subclasses #10976
base: 2.13.x
Are you sure you want to change the base?
Conversation
8676101
to
55255a8
Compare
Added support for default arguments. The behavior differes betwen Java/ConstantAnnotation and other annotations. In 2.13.15:
In order to remain mostly compatible, in this PR:
scala> class ann(x: Int = 1) extends annotation.Annotation
scala> @ann() class K
scala> :power
scala> val info = typeOf[K].typeSymbol.annotations.head
val info: $r.intp.global.AnnotationInfo = ann(1)
scala> info.args.head.tpe
val res1: $r.intp.global.Type = Int(1) @scala.annotation.meta.defaultArg
scala> info.argIsDefault(info.args.head)
val res2: Boolean = true |
ec8804d
to
1a11ace
Compare
Added support for subclassing annotations, so |
In an ordinary application `f(y = b, x = a)`, the compiler needs to create a block with local variables ``` { val x$1 = b val x$2 = a f(x$2, x$1) } ``` in order to preserve evaluation order (`b` before `a`). For annotations `@ann(y = b, x = a)` this is not needed, and it makes annotation processing more difficult / impossible.
... and use the defaults at callsites
Keep the named / default arguments transformation enabled when using annotation classes in executable code. In `new annotation(y = {println("foo"); 2})`, the explicit argument needs to be executed before any defaults.
This adds infrastructure so that the compiler or compiler plugins can support user-defined annotation subclasses.
Updated the PR description with all the changes. I had to introduce a typer mode ( @som-snytt want to take a look? will also pass it by the Scala 3 folks. |
Thanks, Does the same problem exits in Scala 3? |
I'll take a look. I've been following a bit. It's always an event when lrytz adds a mode. |
In an ordinary application
f(y = b, x = a)
, the compiler needs to create a block with local variablesin order to preserve evaluation order (
b
beforea
).For annotations
@ann(y = b, x = a)
this is not needed, and it makes annotation processing more difficult / impossible.This PR disables the named / default arguments transformation for annotations.
Furthermore, when an annotation uses a default argument, the compiler inserts a copy of the default expression AST to the
AnnotationInfo
(instaead of a call to theannot$init$default$1
method):The default expression ASTs are stored in meta-annotations so that they can be recovered later when using an annotation:
This PR also adds support for user-defined annotation subclasses. The
annotationInfo.argsForSuper
method returns the corresponding annotation arguments:Arguments passed to the super annotation are encoded in yet more meta annotations:
Finally, this PR adds support for custom
@nowarn
subclassesFixes scala/scala-dev#884, scala/bug#7656, scala/bug#9612, scala/bug#12367