Use proper initial/frontend version of suspend descriptor
when writing METHOD_FOR_FUNCTION, because serializer uses this version
Also this commit contains adjustments of neighboring code to the describe
change
#KT-16093 Fixed
'SuspendFunction$n' class descriptors are created on demand by KotlinBuiltIns (and cached).
On serialization, types constructed with 'SuspendFunction$n' are written as 'Function$n' with extra flag (SUSPEND_TYPE).
On deserialization, corresponding 'SuspendFunction$n' classes are used.
There are several reasons for doing this:
- See org.jetbrains.kotlin.serialization.deserialization.descriptors.DeserializedMemberScope.computeDescriptors,
classifiers are being deserialized in the last turn, so it's necessary to preserve consistent order
- Their priority should be close to classes
Rework backing field generation logic in PropertyCodegen to switch the
ClassBuilder instance for a multifile part to that of the corresponding facade
class. This became needed because multifile parts, and their metadata, are
generated _before_ the multifile facade class and otherwise we would never
record that there's a synthetic '$annotations' method for a const val and would
not write that to the protobuf message for the property.
See also bad83200
#KT-10892 Fixed
Use the same component (NotFoundClasses) as in loading of compiled Kotlin
symbols.
Some tests were changed to avoid a diagnostic that is now reported when a
non-found class is encountered in a signature (e.g. staticMethod.1.java where
JDK seems to be not configured)
#KT-10493 Fixed
#KT-10820 Fixed
#KT-11368 Fixed
Fake overrides are still created for java static with non-empty overriddenDescriptors
Add tests for inheriting visibility for java static members
Add test: check that java static declarations that shadow deprecated declarations should not be deprecated
Add test for corner case where "overriding" java static constant led to incorrect type in inheritor
Fix test data for existing tests
Java nullability annotations may generate types that currently are not denotable in Kotlin:
class Java {
void <F> foo(@NotNull F f) {}
}
Type of given value parameter should be not nullable under any substitution:
String/String?/String! because of annotation contract.
NB: Currently there is no full analogues for such types in pure kotlin
Mikhail Zarechenskiy