Make sure SENSELESS_COMPARISON
is absent in this case.
^KT-64089 Obsolete
Merge-request: KT-MR-13754
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
It started failing because of other
changes having been merged right before it
^KT-64644 Fixed
Merge-request: KT-MR-13755
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Java resolving subsystem requires calculated visibility for correct disambiguation of supertypes.
But visibility remains `Unknown` for Kotlin class-like declarations during supertypes resolving because `STATUS` resolve phase is performed after `SUPER_TYPES` phase.
To fix the problem, the visibility should be initialized to public at the FIR building phase if no modifier is presented.
^KT-64127 Fixed
When performing lookahead for local variable assignments, make sure
assignments taking place within loops are being propagated before loops.
This makes sure smartcasts within non-inline declarations before the
loop are disallowed.
^KT-63867 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.
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
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
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
There are many complications with the current design of passing data
from within in-place lambdas to surrounding code. Solving these
complications will involve more time to investigation than is available
within the K2 release. So we are disabling passing type statement
information from lambdas for the time being until more time can be
devoted to a more complete solution.
^KT-60958 Fixed
^KT-63530 Fixed
This commit addresses a scenario where an 'actual' declaration is marked
with a Deprecated annotation at the 'Hidden' level, while the
corresponding 'expect' declaration is not. When resolving,
'CheckHiddenDeclaration' marks the 'actual' declaration as unsuccessful,
leading to the selection of the 'expect' declaration as the successful
candidate.
'FirDeprecationChecker' handles a case where an 'actual' class is
annotated with Deprecated, but the 'expect' class is not. During the
checking of the 'actual' class constructor, 'CheckHiddenDeclaration'
skips it due to the absence of a direct Deprecated annotation.
'FirDeprecationChecker' then identifies this constructor and reports a
DEPRECATION_ERROR.
'FirDeprecationChecker' will now be applied to solving problems related
to 'actual' declarations with corresponding Deprecated annotations. The
process remains the same: 'CheckHiddenDeclaration' will skip the
'actual' declaration, and then 'FirDeprecationChecker' will identify it
and report the error.
^KT-61792 Fixed
MT stands for "modularized tests"
^KT-64166 Fixed
Review: https://jetbrains.team/p/kt/reviews/13517/timeline
This commit fixes:
java.lang.IllegalArgumentException: Local <local>/<anonymous> should never be used to find its corresponding classifier
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirProviderImpl.getFirClassifierByFqName(FirProviderImpl.kt:252)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirProviderImpl$SymbolProvider.getClassLikeSymbolByClassId(FirProviderImpl.kt:60)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.computeClass(FirCachingCompositeSymbolProvider.kt:131)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.access$computeClass(FirCachingCompositeSymbolProvider.kt:27)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider$special$$inlined$createCache$1.invoke(FirCachesFactory.kt:75)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider$special$$inlined$createCache$1.invoke(FirCachesFactory.kt:69)
at org.jetbrains.kotlin.fir.caches.FirThreadUnsafeCache.getValue(FirThreadUnsafeCachesFactory.kt:40)
at org.jetbrains.kotlin.fir.resolve.providers.impl.FirCachingCompositeSymbolProvider.getClassLikeSymbolByClassId(FirCachingCompositeSymbolProvider.kt:158)
at org.jetbrains.kotlin.fir.resolve.transformers.mpp.FirExpectActualResolver.findExpectForActual(FirExpectActualResolver.kt:41)
Static scope is checked first during resolution
(scopes are in reverse order).
This fixes a difference between how K1 and K2 resolve annotations.
#KT-63249 Fixed
When we check Java field for constant initializer, we could
be asked to get and check the type of Kotlin's property that
is used in this Java field. But there is no guarantee that the type
resolve phase was finished and this type is available. So we just
check for `const` modifier and skip type check.
#KT-63752 Fixed
#KT-62558 Obsolete
#KT-61786 Declined
Ivan Kochurkin