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
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
Currently it's only used for local type aliases, while code in
'deserializeTypeAlias' works properly only for nested or top-level type
aliases.
Also it seems that serialization of types based on local type aliases
doesn't work now anyway (see KT-13692)
If deserializing a type with arguments based on a local class for
decompiler, then just return Any type (without arguments).
Previously Any constructor was used with serialized arguments, that lead
to exception
Note that in case of deserialization for compiler nothing changes about
local-classes-based types (LocalClassifierResolverImpl is just inlined)
#KT-13408 Fixed
Do not create StringBuilder instances when the resulting String will be
appended to some other StringBuilder anyway. This, and a couple of micro
FqNameUnsafe-related optimizations, helps reduce memory traffic in Kotlin
reflection when rendering is involved (toString() is called on reflective
objects)
Both primitive int and wrapper type java.lang.Integer are represented by the
single type kotlin.Int in Kotlin, so inequality between the corresponding
KClasses was confusing here. To keep the old behavior, one may call 'k1.java ==
k2.java' instead of `k1 == k2`
#KT-13462 Fixed
As in KClassifier.createType and everywhere in the compiler, specify arguments
for the innermost type first. This is more convenient to use because generally
the construction/introspection of such type starts from the innermost class
anyway (i.e. something like generateSequence can be used, without the need to
call .reverse() in the end)
Denis Zharkov