The problem was that we tried to generate an `$annotations` method for a
property declared in an annotation class. That method is final and has a
body, which is not allowed in annotation classes. Now we're generating
this method in the separate `$DefaultImpls` class as for properties in
interfaces.
Note that the added test still doesn't find any annotations because the
proper support is needed in reflection (KT-22463). Currently it only
checks that no VerifyError happens.
They are currently marked as defined even when they get a
default implementation. That makes it hard to figure out
if the accessor should be removed when introducing a backing
field in the JVM_IR backend.
Introduce MetadataSource as a way to store the original descriptor for
any element (before any lowerings) and maintain it until the end of the
codegen where it's used in generating the metadata. Note that JVM
signatures written to the metadata are formed from the _resulting_
generated elements, not by mapping the original descriptors.
Some corner cases are not supported yet, namely properties declared in
companion objects, synthetic methods for property annotations,
JvmPackageName, etc.
#KT-29119 Fixed
Otherwise we're not trying to load annotations on the parameter of the
property setter in MemberDeserializer.loadProperty.
Note that after this commit, we could now also assume that if
getter/setter is default, it has no annotations, and thus use
Annotations.EMPTY for default getter/setter in loadProperty. However,
this would cause reflection to work incorrectly on classes compiled by
an older Kotlin compiler, so we'll still try to load annotations on
default accessors for an indefinite time.
#KT-25499 Fixed
In MemberDeserializer.loadProperty, we incorrectly passed 0 to
getAnnotations when loading annotations on property accessors in case
the protobuf field getter_flags/setter_flags was not present. The
correct behavior, as described in metadata.proto, was to pass a special
"default accessor flags" value, constructed from the main property
flags. Otherwise in case there were annotations both on the property and
on the accessor (as in PropertyAndAccessor.kt) and the accessor was
otherwise default, we would assume that it had no annotations and would
not load them in compiler and reflection
#KT-25499 In Progress
Make it possible to specify annotations of the setter parameter when
constructing the default setter via DescriptorFactory; pass the split
annotations in DescriptorResolver.resolvePropertySetterDescriptor
#KT-25500 Fixed
This change would also make NotNull annotations to be generated on
non-primitive annotation methods, but we skip this deliberately because
annotation methods never return null on JVM anyway
#KT-25287 Fixed
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
