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
Effectively all custom logic was moved from MemberIndex to JavaScope classes,
and as member names are being cached there, so it prevents repeating supertypes
traversal (see getAllMemberNames extension)
Do not use memoized function if member with given name is not contained in the scope
There are a lot of queries with names of non-existent functions, that leads to many
effectively redundant Map nodes in MemoizedFunction and also cause
additional computation that is worth to compute at once
To indicate that repeating calls to them may require additional computations
Also change second parameter to be nullable, this will be necessary in the next commits
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
Do not use memoized function if member with given name is not contained in the scope
There are a lot of queries with names of non-existent functions, that
leads to many effectively redundant Map nodes in MemoizedFunction and also cause
additional computation that is worth to compute at once
Also drop unused 'location' parameter
Also provide some basic implementation
The main purpose of these methods is optimization.
Most of the member scopes store mapping from names to descriptors
MemoizedFunction<Name, Collection<Descriptor>>
While there are 10 functions in class in average, there are a lot of
queries with names of non-existent functions, that leads to many
effectively redundant Map nodes in MemoizedFunction and also cause
additional computation that is worth to compute at once
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
Alexey Tsvetkov