Move parts of the logic to the only places where they're needed:
checking for public/final/val is only needed in
JvmFieldApplicabilityChecker, checking the proto flag is only needed in
reflection, checking the JvmField annotation presence is only needed in
backend
There are cases when members deserialized from JVM classes have no JVM
signature in the proto. For example, if a member is inherited from a
built-in class (such as Map.getOrDefault in some Map implementations),
or if a member is synthesized in the compiler front-end and back-end
separately (such as enum values/valueOf). In these cases, we'll use the
naive type mapping to try to recover the signature.
#KT-16616 Fixed
#KT-17542 Fixed
There's still some blind spots:
- Covariant overrides in Java (KT-25036)
- Current implementation assumes that when language version is 1.3 every suspend function
reference only release-coroutines-package Continuation
(we need to check if it's a correct statement)
#KT-24848 Fixed
#KT-25036 Open
Introduce a method to create org.jetbrains.kotlin.load.kotlin.MemberSignature directly from JvmMemberSignature.
Create JvmFunctionSignature from JvmMemberSignature.
They are hardcoded to avoid having dependency from android.jar on
our annotations' jar with UnderMigration.
Even while it could be a compile-only dependency we need to make sure
that annotated types are read properly without RecentlyNonNull/RecentlyNullable
in the classpath
#KT-24278 Fixed
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
There are two reasons for this. First, this class will be used in the
metadata reading library which should not have dependencies on lots of
compiler stuff JavaToKotlinClassMap depends on.
Second, it was easy to accidentally break the deserialization in old
compilers by adding another mapping to JavaToKotlinClassMap. This was
possible because ClassMapperLite is used to decide whether or not the
JVM signature is "trivial" and should be written to the metadata (at
JvmSerializerExtension.SignatureSerializer.requiresSignature). If the
signature is trivial but mentions a type added in JavaToKotlinClassMap
in the new compiler, the old compiler will not be able to load the
signature correctly. See the comment on ClassMapperLite for more
information
Alexander Udalov