Java parser skips over annotations, all @interfaces have the default @Retention
#8928
Comments
|
Imported From: https://issues.scala-lang.org/browse/SI-8928?orig=1 |
|
@soc said: |
hrhino
added a commit
to hrhino/scala
that referenced
this issue
May 7, 2017
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
Review by @densh
Fixes scala/bug#8928
hrhino
added a commit
to hrhino/scala
that referenced
this issue
May 7, 2017
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
Review by densh
Fixes scala/bug#8928
hrhino
added a commit
to hrhino/scala
that referenced
this issue
May 8, 2017
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
Review by densh
Fixes scala/bug#8928
hrhino
added a commit
to hrhino/scala
that referenced
this issue
May 9, 2017
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
Review by densh
Fixes scala/bug#8928
hrhino
added a commit
to hrhino/scala
that referenced
this issue
Jun 29, 2017
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
The new tests are run-tests not just pos-tests at the suggestion
of retronym, to ensure that everything works the same at runtime
as it does at compile time. As a matter of fact, it doesn't: the
compile-time universe maintains ordering of annotation values in
the tree, while the runtime universe uses java reflection to get
at the values and therefore cannot know of their order. The test
contains one exception for that.
Review by densh, retronym
Fixes scala/bug#8928
hrhino
added a commit
to hrhino/scala
that referenced
this issue
Jul 6, 2017
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
The new tests are run-tests not just pos-tests at the suggestion
of retronym, to ensure that everything works the same at runtime
as it does at compile time. As a matter of fact, it doesn't: the
compile-time universe maintains ordering of annotation values in
the tree, while the runtime universe uses java reflection to get
at the values and therefore cannot know of their order. The test
contains one exception for that.
Review by densh, retronym
Fixes scala/bug#8928
dwijnand
pushed a commit
to dwijnand/scala
that referenced
this issue
Feb 27, 2020
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
The new tests are run-tests not just pos-tests at the suggestion
of retronym, to ensure that everything works the same at runtime
as it does at compile time. As a matter of fact, it doesn't: the
compile-time universe maintains ordering of annotation values in
the tree, while the runtime universe uses java reflection to get
at the values and therefore cannot know of their order. The test
contains one exception for that.
Review by densh, retronym
Fixes scala/bug#8928
Co-authored-by: Jason Zaugg <jzaugg@gmail.com>
dwijnand
pushed a commit
to dwijnand/scala
that referenced
this issue
Mar 2, 2020
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
The new tests are run-tests not just pos-tests at the suggestion
of retronym, to ensure that everything works the same at runtime
as it does at compile time. As a matter of fact, it doesn't: the
compile-time universe maintains ordering of annotation values in
the tree, while the runtime universe uses java reflection to get
at the values and therefore cannot know of their order. The test
contains one exception for that.
Review by densh, retronym
Fixes scala/bug#8928
Co-authored-by: Jason Zaugg <jzaugg@gmail.com>
dwijnand
pushed a commit
to dwijnand/scala
that referenced
this issue
Mar 24, 2020
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
The new tests are run-tests not just pos-tests at the suggestion
of retronym, to ensure that everything works the same at runtime
as it does at compile time. As a matter of fact, it doesn't: the
compile-time universe maintains ordering of annotation values in
the tree, while the runtime universe uses java reflection to get
at the values and therefore cannot know of their order. The test
contains one exception for that.
Review by densh, retronym
Fixes scala/bug#8928
Co-authored-by: Jason Zaugg <jzaugg@gmail.com>
dwijnand
added a commit
to dwijnand/scala
that referenced
this issue
Apr 22, 2020
This causes the java parser to get somewhat more complex, but
allows for macros and compiler plugins to correctly inspect
java-defined classes for annotations.
Moved a few utility methods into {Parsers,Scanners}Common as well,
so I can reuse them in the java ones.
This involves a change to the t4788 tests, as SAnnotation now
correctly has RetentionPolicy.SOURCE, and is therefore ignored
by the check in BCodeHelpers#BCAnnotGen.shouldEmitAnnotation;
also, ASM Textifier emits an // invisible marker now that
CAnnotation has RetentionPolicy.CLASS. I'm not sure what the
chances that anyone is relying upon this behavior are, but
since it does the Right Thing for separate compilation runs,
they probably should not be too disappointed.
The new tests are run-tests not just pos-tests at the suggestion
of retronym, to ensure that everything works the same at runtime
as it does at compile time. As a matter of fact, it doesn't: the
compile-time universe maintains ordering of annotation values in
the tree, while the runtime universe uses java reflection to get
at the values and therefore cannot know of their order. The test
contains one exception for that.
Review by densh, retronym
Fixes scala/bug#8928
Co-authored-by: Jason Zaugg <jzaugg@gmail.com>
Co-authored-by: Dale Wijnand <dale.wijnand@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since scala/scala#4026 we respect
@Retentionon java annotation classes.When the annotation class is parsed from source, the meta-annotation is skipped. In #8926 we changed the default visibility back to
RUNTIMEfor annotations without a@Retentionmeta-attribute.Instead, we should extend the java parser.
The text was updated successfully, but these errors were encountered: