The main motivation for this change is that
java.lang.annotation.Repeatable has a parameter for the container
annotation, which is lost during conversion to
kotlin.annotation.Repeatable. To support j.l.a.Repeatable in backend
properly, it's absolutely necessary to be able to load the container
annotation for any repeatable annotation class, so the original
j.l.a.Repeatable needs to be stored in the descriptor and accessible
from the backend.
Instead of mapping j.l.a.Repeatable -> k.a.Repeatable, add a frontend
service PlatformAnnotationFeaturesSupport that will determine if an
annotation is repeatable "according to the platform rules", which for
JVM means that it's annotated with j.l.a.Repeatable.
Some effects of this change include:
- Usages of j.l.a.Repeatable are no longer reported as "deprecated", the
corresponding test is deleted
- Usages of repeatable annotations declared in Java with non-SOURCE
retention with LV 1.5 and earlier will now result in a slightly
different error (REPEATED_ANNOTATION instead of
NON_SOURCE_REPEATED_ANNOTATION)
#KT-12794
Since it's not feasible to support annotated types in 1.6, we're making
this an explicit error in 1.6, so that typeOf can become stable and this
feature can be supported in the future without breaking changes to the
existing code.
Note that extension function types are a special case of annotated
types. A separate error is created for them just because the message
"annotated types are not supported" would be confusing, since such types
don't have explicit annotations in the source code.
#KT-29919
Otherwise an invalid type is constructed which causes kotlin-reflect to
crash, and stdlib implementation to render the type incorrectly. The
reason is that suspend functional types are not properly supported in
reflection. Once they are supported, this error can be removed.
#KT-47562
Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
Add extension point for java descriptors
Add simple usage of this point to generate getter method
Add simple test infrastructure to test compilation with lombok plugin
KotlinJvmBinaryClass.AnnotationArrayArgumentVisitor didn't cover the
case when the element type is an Annotation. Therefore, when the
compiler read an array of annotations from JVM binary classes built from
Kotlin sources, it got an empty array regardless of what was written in
the bytecode.
For example, Foo.value below is read as an empty array when SomeClass
resides in another Kotlin module.
@Foo(
value = [Bar(1), Bar(2)]
)
class SomeClass
Alexander Udalov