This commit gets rid of the redundant typeApproximatorConfiguration
in Fir2IrTypeConverter and uses the type approximator for captured
types instead of the manual approximation used before.
This fixes the nullability of approximated captured types, which fixes
a runtime error in WASM.
This also brings K2 IR closer to K1 IR in one test.
#KT-64261 Fixed
Previously, we would ignore the candidate with the non-smartcasted
receiver if they have the same symbol.
Now we prefer them when they're visible or when the smart cast changes
the nullability.
This is required for the following commit where candidates from the
original scope in presence of smart cast will not be ignored if they're
the same symbol.
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
Before this commit, we assumed (erroneously) that a captured type
cannot have an associated SAM-based function type.
In this commit we changed this assumption, replacing a captured type
with its lower type for this purpose
#KT-63379 Fixed
We cannot skip resolution in the case of type actualization as we cannot
guaranty that there are no any classes in super types which can be
actualized in the current context
^KT-62832 Fixed
^KT-63547
Before this commit, we discriminated particular candidates with callable
reference adaptations during resolution stages.
After disabling compatibility mode for new inference, it's not so,
but now we discriminate similar candidates in ConeOverloadConflictResolver;
more precisely, it's candidates with callable reference adaptation
in their postponed atoms.
This does not allow going up the tower,
but allows to select better candidate at similar tower level.
Related to KT-63558, KT-64307, KT-64308
Before this commit, we discriminated particular candidates with SAM
during resolution stages. More precisely, candidates from Kotlin
which used Java SAM types, were discriminated allowing go up the tower
for better candidates. After disabling compatibility mode for new
inference, it's not so, but now we discriminate similar candidates
in ConeOverloadConflictResolver. This does not allow going up the tower,
but allows to select better candidate at similar tower level.
Related to KT-63558, KT-64306
Otherwise, if complex expressions such as when expressions are
used in combination with the intrinsics we get incorrect stepping
behavior.
^KT-64341 Fixed
The problem from KT-63624 was that during matching phase we must choose
only one candidate, but in Java we can have two successfully matched
properties: 1) from field and 2) from method, which overrides Kotlin
property.
See test `propertyAgainstJavaPrivateFieldAndPublicMethod.kt`.
As a result, we choose field candidate, throw away method candidate, and
then fail during visibility check.
Instead of inventing special rule of prioritizing field over method
it was decided to prohibit actualization to Java field at all because:
1. It doesn't seem that Java fields actualization was implemented in K1
on purpose
2. People usually don't use public Java fields, and use instead
private field + getter, especially when compatibility is important, so
it shouldn't be a breaking change
Besides that, such solution simplifies code and is consistent with
the current logic of matcher, which doesn't expect that two members
can be matched successfully. Also, it fixes KT-63624 and KT-63667.
^KT-63624 Fixed
^KT-63667 Fixed
During the fix of KT-62525, we've forbidden to use lambda parameters
with inaccessible types at all. After it, some impact was noticed,
so we decided to forbid them only in case it's necessary
(the case when associated types have type arguments, see KT-62525
description), and to deprecate them in other cases.
#KT-64266 Fixed
Kirill Rakhman