23 invokes in KFunctionFromReferenceImpl (and consequently, in FunctionImpl)
were needed before 1576160390: a wrapped function
reference must have had the necessary invoke to be called as an instance of a
specific function type. After 1576160390, this is
not needed anymore because KFunctionFromReferenceImpl is now an internal
implementation detail of reflection, and no invoke is ever called on it.
The only place where their get/set methods were used was in
KPropertyNImpl.Getter.invoke, and it's fine if that results in a reflective
call instead (KPropertyN#getter is not available without kotlin-reflect.jar
anyway). The test data has been changed because a package local Java field is
not accessible via reflection
Most of KClassImpl operations should be cached, but creating a lazy value for
each operation would significantly increase memory footprint of a KClassImpl
instance. Therefore we decide to store all lazy values under a single lazy
value named 'data' which is stored in KClassImpl. There's a minor overhead of
indirection on any operation now, however it'll allow us to substantially
increase reflection performance by caching everything we can
Generation of callable reference's signature in codegen should use the same
mechanism for obtaining the signature as the runtime in RuntimeTypeMapper,
namely DescriptorUtils.unwrapFakeOverride(...).original
#KT-13700 Fixed
Do not treat members with already changed signature as a reason
to create a hidden copy
See tests for clarification:
- There are `charAt` method in B that has different name in Kotlin - `get`,
i.e. relevant descriptor has initialSignatureDescriptor != null
- When collecting methods from supertypes, `charAt` from A is also get
transformed to `get`
- So it has effectively the same signature as B.get (already declared)
- If by an accident B.get had been declared with Kotlin signature
we would have add A.charAt (after transformation) with special flag:
HiddenToOvercomeSignatureClash (hides it from resolution)
- But here B.charAt was artificially changed to `get`, so no signature clash
actually happened
#KT-13730 Fixed
It's necessary for proper recovering of classId by plain string JVM descriptor when loading annotations
See FileBasedKotlinClass.convertAnnotationVisitor
Related tests are already exist in loadJava, but they stopped working
after the recent changes:
nested classes are not found anymore by name with '$' symbol
Do not split descriptors into declared/non-declared groups
It should not be important as order of non-declared members' appearance
does not affect stub building, deserialization and other order-sensitive
stuff
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
Dmitry Petrov