Use it in LazyJavaPackageFragment#scope instead of a weird lazy chained scope.
Also move lookup tracker records to it, to prevent them from being written in
each package scope individually (this was hurting performance)
It can be used to specify enhanced signature for standard JDK methods
without them be actually annotated
#KT-9194 In Progress
#KT-5175 In Progress
#KT-10370 In Progress
#KT-7127 In Progress
- Move components from LazyJavaResolverContext to JavaResolverComponents
- Drop LazyJavaClassResolver replacing it's usages with module resolver
(now enum entries from another module as annotation arguments are being resolved, see test)
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.
Alexander Udalov