To be more precises, ResultTypeResolver for K2 now searches for
similar LOWER/UPPER constraints pair based on the same flexible type,
like LOWER(CapturedType&Any..CapturedType?) and UPPER(CapturedType!).
If such a pair is found, the CapturedType is not approximated.
This is done to avoid a big difference between this case and
completely same constraints, like LOWER(CapturedType!) and
UPPER(CapturedType!). In this case we squash them to EQUAL(CapturedType!)
even before ResultTypeResolver, and captured types which is got from
an EQUAL constraint are not approximated even before this commit.
This commit fixes back a case from KT-50134 and a problem with intellij.vcs.git
#KT-65596 Fixed
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
This commit is intended to deal with inconsistency in K1/K2
star projection handling.
K1 star projection includes a 'type' property.
This type from a star projection can be used for relevant
functions / properties return types,
and already includes some approximation for recursive generics.
In contrast, K2 star projection is an object,
and return types of relevant functions / properties are
represented as captured types.
To prevent recursion in them in recursive generic case,
this commit includes additional replacement of their type arguments.
See more details in added comments.
#KT-65057 Fixed
This diagnostic is reported on an explicitly-declared function which
overrides a regular Java function with the same signature as a hidden
one from the same scope.
#KT-64846 Fixed
In this commit we started to create and process a hidden copy
for a built-in functions, which value parameters are erased in Java,
in case we have an accidental Java override which value parameters
are not erased.
In this situation attempt to override such a Java override in Kotlin
again will lead to inaccessible functions
(see changes in containsAndOverload.fir.kt)
#KT-64846 In Progress
We drop Kotlin function 'remove' or 'getOrDefault' from JvmMappedScope,
if it has platform-dependent annotation, and the bound Java class scope
does not contain a function with the same signature.
#KT-57268 Fixed
In more details, we use either platform override checker (if we came
from platform) or the combined intersection scope override checker
at this place. Also this commit fixes various places around
JavaOverrideChecker, allowing to apply it in intersection override
checker properly:
- don't consider return types in this place
- apply JavaOverrideChecker if at least one candidate is from Java
- compare type primitivity closer to K1 logic
#KT-62554 Fixed
Partially fixes KT-63242
To call retrieveDirectOverriddenOf,
one must use directly the owner scope of a callable symbol we consider,
and not a scope of some derived class.
#KT-64276 Fixed
This commit fixes two tests related to removed workaround of KT-59818,
and also makes processing suspend functions in J/K hierarchy more consistent.
Before this commit, when we had Java class "suspend" method
(implemented with the help of Continuation) overriding Kotlin suspend fun,
the Kotlin suspend fun was visible in outer use-site scope,
and the Java method was invisible.
Also, we used a special "Java suspend view" just to determine
that Java method overrides Kotlin suspend fun and no more.
After this commit, Java class "suspend" method will be visible
in this hierarchy and Kotlin suspend fun will not.
Also, the "suspend" is visible as a synthetic Kotlin suspend fun
which is more correct.
Related to KT-63233
#KT-59818 Fixed
This commit breaks two diagnostic tests:
- testSuspendJavaImplementationFromDifferentClass
- testSuspendJavaOverrides
Related to KT-59818
#KT-63233 Fixed
FirJavaMethod and FirJavaConstructor are implementation classes.
It's anyway not good to check subtyping using them,
because it makes the code implementation-dependent.
This commit begins to check Java origin instead.
We used this classId to get an associated symbol,
but this way is anyway not recommended (e.g. problems with local classes).
In this commit we migrated to usage of lookup tags instead.
Mikhail Glukhikh