Avoid overeager completion of Java annotations in classfile parser #15185
Conversation
|
The issue in #15166 does not occur with the Scala 2 compiler because it does not perform the scan for pickle signature annotations without first observing the As an alternative to the fix here in 1df17bb, we could potentially do the same, but we currently have and so we'd also have to gate the checks for We could drop support for those, or if used in the future, could we stipulate that we would also need to emit a corresponding attribute ( |
No, those look like abandoned experiments that can safely be removed. |
When scanning for Scala pickling annotations, all annotations in all classfiles (including those produced by the Java compiler) are considered. Before this commit, a Type and Symbol were created for each discovered annotation and comparared to the known Scala signature annotation types. In certain situations (as in tests/pos/i15166), this is problematic, as the denotation of an annotation symbol defined as a Java inner class may be forced before the inner class table is populated and setClassInfo is called on the class root. Comparing names (as strings) rather than type symbols avoids this situation. Fixes scala#15166
An alternative fix for scala#15166, which aligns with the behavior of the Scala 2 classfile parser. Before this commit, all classfiles, including those produced by the Java compiler and compilers of other JVM languages, were scanned for Scala pickling annotations. In certain situations (as in tests/pos/i15166), this is problematic, as the denotation of an annotation symbol defined as a Java inner class may be forced before the inner class table is populated and setClassInfo is called on the class root. We avoid this situation by only performing the pickling annotation scan for those classfiles having the `ScalaSig` attribute, i.e. those produced by the Scala 2 compiler. We also drop support for pickling TASTy using the classfile annotations `scala.annotation.internal.TASTYSignature` and `scala.annotation.internal.TASTYLongSignature`. These were never used by the compiler, there are no plans for future use, and preserving support would complicate this fix.
griggt
changed the title
griggt
added
the
backport:nominated
|
@griggt 🎉 |
griggt
added
backport:accepted
griggt
added
backport:done
Require observing the
ScalaSigattribute in a classfile before scanning for Scala pickling annotations, which aligns with the behavior of the Scala 2 classfile parser.Before this commit, all classfiles, including those produced by the Java compiler and compilers of other JVM languages, were scanned for Scala pickling annotations. In certain situations (as in tests/pos/i15166), this is problematic, as the denotation of an annotation symbol defined as a Java inner class may be forced before the inner class table is populated and setClassInfo is called on the class root.
We avoid this situation by only performing the pickling annotation scan for those classfiles having the
ScalaSigattribute, i.e. those produced by the Scala 2 compiler.We also drop support for pickling TASTy using the classfile annotations
scala.annotation.internal.TASTYSignatureandscala.annotation.internal.TASTYLongSignatureThese were never used by the compiler, there are no plans for future use, and preserving support would complicate this fix.
Fixes #15166