^KT-59938 Fixed
Review: https://jetbrains.team/p/kt/reviews/13760
After this patch:
> The /compiler/testData/diagnostics/tests/multiplatform/topLevelFun/conflictingImplDeclarations.kt test:
Fixed
> The /compiler/testData/diagnostics/tests/multiplatform/headerClass/expectDeclarationWithWeakIncompatibilities.kt test:
Declarations are in the same module. `PACKAGE_OR_CLASSIFIER_REDECLARATION` is reported anyway
> The /compiler/testData/diagnostics/tests/multiplatform/java/varPropertyAgainstJavaGetterAndNonFinalField.kt test:
Expect-actual matcher doesn't match fields in K2 https://youtrack.jetbrains.com/issue/KT-63667 => green code
> The /compiler/testData/diagnostics/tests/multiplatform/java/propertyAgainstJavaPrivateFieldAndPublicMethod.kt test:
Expect-actual matcher doesn't match fields in K2 https://youtrack.jetbrains.com/issue/KT-63667 => green code
> The /compiler/testData/diagnostics/tests/multiplatform/java/implicitJavaActualization_multipleActuals.kt test:
K2 doesn't have implicit Java actualization. And PACKAGE_OR_CLASSIFIER_REDECLARATION is reported anyway
> The /compiler/testData/diagnostics/tests/multiplatform/java/propertyAgainstJavaPublicFieldAndPublicGetter.kt test:
Expect-actual matcher doesn't match fields in K2 https://youtrack.jetbrains.com/issue/KT-63667 => green code
> The /compiler/testData/diagnostics/tests/multiplatform/actualClassifierMustHasTheSameMembersAsNonFinalExpectClassifierChecker/injectContextReceiverOverload.kt test:
Context receivers are not supported in expect-actual matcher. https://youtrack.jetbrains.com/issue/KT-61447
And K2 reports another error right now anyway
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
It was decided to leave this code as is, because supporting
it would probably require introducing Implication-statements,
but this is not a good-enough use-case for such work.
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>
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
There might be several pathes out from the function from CFG point of view:
- normal execution path
- exceptional execution path
For verification of callsInPlace contract it's needed to check only
the normal path
^KT-63414 Fixed
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
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
The reason of this change is to make messages (especially warnings)
that are reported by the KLIB resolver become visible to the end user.
This can be achieved to forwarding such messages to the appropriate
compiler's components such as
`org.jetbrains.kotlin.cli.common.messages.MessageCollector` and
`org.jetbrains.kotlin.ir.util.IrMessageLogger`.
Also: The default `DummyLogger` should be used as minimal as possible.
Because it just forwards messages to the standard output (console)
where they can remain unattended. When the compiler is executed
from the Gradle plugin such messages appear only in DEBUG Gradle's log.
^KT-63573
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
Nikita Bobko