The main change is in AbstractBinaryClassAnnotationAndConstantLoader, where we
no longer perform unnecessary IO operations for classes which are already
loaded to memory
Introduce LightMemberOriginForCompiledElement which holds logic for finding corresponding decompiled declaration
ByJvmSignatureIndexer stores the required information while building decompiled text
Some are unsolved in this commit:
- constructors
- @Jvm* and other unregular generated members
- annotation methods
#KT-11678 Fixed
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
Load immutable flexible upper bound for 'Iterable<? super T>'
We load 'Collection<? super CharSequence>' as 'MutableCollection<in CharSequence>'
instead of 'MutableCollection<in CharSequence>..Collection<*>'
because it's obviously not typesafe to use any 'Collection<*>'
as argument for such type.
But there'se nothing bad with loading 'Iterable<? super CharSequence>'
as 'MutableIterable<*>..Collection<*>'. Same for other declarations that have
covariant mutable representation (currently Iterator, ListIterator).
Also there are useful use-cases when it's neccessary to use 'Iterable<*>'
as an argument for parameter with type 'Iterable<? super T>' (see matchers.kt test).
NB: Star-projections appear in examples because types like 'Collection<in CharSequence>'
with conflicting use-site projections are invalid in Kotlin, but they are valid in Java.
It helps to get rid of semantics duplicating and fixes known bugs
- SOE in OnlyAbstractMethodFinder.find
- type enhancement for SAM constructors
#KT-11287 Fixed
#KT-11322 Fixed
EA-77989 Fixed
Mostly it's about detecting loops in supertypes
Test data changes:
- Loops are being disconnected in Java classes too
- functions.kt: loops disconnection mechanism runs supertypes calculation,
so when we start check T it forces F' supertypes calculation, that ends
with CYCLIC_GENERIC_UPPER_BOUND reported on F
#KT-11287 In Progress
Stanislav Erokhin