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
Fake overrides are still created for java static with non-empty overriddenDescriptors
Add tests for inheriting visibility for java static members
Add test: check that java static declarations that shadow deprecated declarations should not be deprecated
Add test for corner case where "overriding" java static constant led to incorrect type in inheritor
Fix test data for existing tests
Currently 'overriddenDescriptors' of substituted function is lazy
and in most cases it's unnecessary to compute it
(it's enough to use the same field from 'original')
Java nullability annotations may generate types that currently are not denotable in Kotlin:
class Java {
void <F> foo(@NotNull F f) {}
}
Type of given value parameter should be not nullable under any substitution:
String/String?/String! because of annotation contract.
NB: Currently there is no full analogues for such types in pure kotlin
Pavel V. Talanov