^KT-64187 Fixed
Review: https://jetbrains.team/p/kt/reviews/14807
I also checked that IDE sets metadataCompilation to `true` (Actually, it
looks like IDE performs analysis two times with the flag having
different values, but whatever, maybe it's even better this way)
Review: https://jetbrains.team/p/kt/reviews/14807
Motivation: no motivation, I was just passing by and noticed this bug.
It looks like this commit doesn't affect any tests
Before this commit, the expect-actual resolver could find expects in
regular dependencies
Note: The appeared `VIRTUAL_MEMBER_HIDDEN` in
compiler/fir/analysis-tests/testData/resolveWithStdlib/multiModule/FakeOverrides.kt
isn't caused by my change. It's caused by fixing the testData dependency
syntax notation.
The testData improperly used regular dependency syntax notation, while
it should have been using dependsOn
Before:
Regular dependency syntax notation
// MODULE: androidMain(commonMain)
After:
dependsOn dependency syntax notation
// MODULE: androidMain()()(commonMain)
^KT-61798 Fixed
Review: https://jetbrains.team/p/kt/reviews/14230/timeline
Q: How resolved modality of an accessor affects expect/actual matching
algorithm of properties?
A: It's not expect/actual matching of properties, but expect/actual
matching of properties setter. Declarations (setters in our case) in
actual are allowed to have wider visibility but only if the
appropriate expect is `final`. Before this commit, all property
accessors were always `final` by mistake. After this commit, they
have the modality derived from their containingProperty.
Related problem: PositionStrategy for ACTUAL_WITHOUT_EXPECT can be
improved KT-65720
The fix in `resolveModality` is similar to how `resolveVisibility` works
Related tests:
- ConfigurationCacheForAndroidIT.testKotlinAndroidProject
- FirIdeNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testDelegateInterfaceLibrary
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirIdeNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirIdeNormalAnalysisSourceModuleSymbolByPsiTestGenerated.testEnumEntryOverride
- FirIdeNormalAnalysisSourceModuleSymbolByPsiTestGenerated.testEnumValueMember
- FirStandaloneNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleCombinedDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirStandaloneNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleDeclaredMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- FirStandaloneNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumClassWithAbstractMembers
- FirStandaloneNormalAnalysisSourceModuleMemberScopeTestGenerated.testEnumEntryInitializerWithOverriddenMember
- DiagnosticCompilerTestFE10TestdataTestGenerated*testChangeSetterVisibilityInOverride
Review: https://jetbrains.team/p/kt/reviews/14224/timeline
Timeline:
**(1)** Kotlin 1.1.60 https://github.com/JetBrains/kotlin/commit/59efedf610a25b004edf3d19897ce4dfca28ddb2 `header` keyword is introduced (committed on Dec 13, 2016)
**(2)** Kotlin `header`/`impl` has been deprecated (warning) at least since 1.1.60 https://github.com/JetBrains/kotlin/commit/5d251062677e09d607f295189b7978d5833e448f (committed on Sep 15, 2017)
**(3)** 1.1.60 release https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-compiler/1.1.60/ Nov 13, 2017
It sounds stupid but it looks like `header` was introduced and
deprecated right in the same release. Though it may be possible that we
had a release between **(1)** and **(2)** that I couldn't find
Anyway the keywords have been deprecated since basically forever
The fix is not perfect
"The perfect fix" would be:
1. Introduce a separate `DEPRECATED_MODIFIER_ERROR` diagnostic
2. Introduce LanguageVersionSettings for the `DEPRECATED_MODIFIER_ERROR`
diagnostic
But "the perfect fix" requires:
1. Adopting `ReplaceModifierFix` in the IDE to make it work with the new
diagnostic. `ReplaceModifierFix` is only implemented in K1 IDE. So
there are two ways:
1. Create a KTIJ ticket to port the diagnostic to K2 IDE (it needs to
be ported anyway), and **mention** in the ticket that
`DEPRECATED_MODIFIER_ERROR` also needs to be supported in K2 IDE.
It's the ticket that nobody will probably find and fix
2. Go and port `ReplaceModifierFix` to K2 IDE myself. It's fairly
simple task, but I've not worked in intellij for quite a while,
and it will take me too much time to index and compile
Considering that DEPRECATED_MODIFIER diagnostic is used only to report
`header`/`impl`, and there are literally 0 known cases when people use
it. It's just easier to convert the diagnostic to error in K2
Related tests:
- compiler/testData/diagnostics/tests/multiplatform/deprecated/header.kt
^KT-59839 Fixed
^KT-62547 Fixed
I also tested the commit by disabling DfaBooleanVariables in all tests
and checking what tests will fail
I didn't find anything that worked in K1, but doesn't work in K2 with
DfaBooleanVariables disabled
Related tests:
- DiagnosticCompilerTestFirTestdataTestGenerated$Resolve$Smartcasts
- LLFirPreresolvedReversedDiagnosticCompilerFirTestDataTestGenerated$Resolve$Smartcasts
- PreFirIdeSpecTestGenerated$NotLinked$Dfa
- DiagnosticCompilerTestFE10TestdataTestGenerated$Tests$SmartCasts
- FirPsiDiagnosticTestGenerated$Resolve$Expresssions.testSyntheticSmartCast
^KT-59074 Fixed
This solution is not ideal. Ideally, the allopen compiler plugin
shouldn't report `private` properites as `open` KT-64980, but it will
unpredictably break other things.
This reverts commit 96b2f13397.
Unfortunately, in K2, the feature works only in JVM. KT-56466 The
feature is postponed till 2.2 (preview is postponed till 2.1)
KT-1436
We initially wanted to release the feature in 1.9.0, but found a bug in
K1 KT-54906. It was decided to postpone the feature release to 2.1, but
at this time KOTLIN_2_1 didn't exist
In this commit I make it possible to enable the feature with
-language-version 2.1 flag, so users can "preview" this feature in 2.0
KT-1436
^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
Motivation: AMBIGUOUS_ACTUALS can't be reported on frontend (because it
requires expect to actual mapping, but the mapping is only available on
backend)
In scope of KT-59938
Review: https://jetbrains.team/p/kt/reviews/13760
^KT-64121 Fixed
Review: https://jetbrains.team/p/kt/reviews/13495/timeline
If we generate these declarations then the compiler sees Any.{toString,
equals, hashCode} non-synthetic declarations of common metadata and
reports false positive ACTUAL_MISSING during intermediate (HMPP)
metadata compilation.
See the review for more details
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)
We don't have "expect as libraries" feature yet. But once we have the
feature, the code in question might start silently behave incorrectly.
Add assertions to make sure that the code will fail
Review: https://jetbrains.team/p/kt/reviews/13334/timeline
Thanks to the previous commit, it's now possible to run
DefaultArgumentsInExpectActualizedByFakeOverride on both: frontend (FIR)
and backend (IR).
We aim to perform a thorough examination of checks involving
fake-overrides on both FIR and IR, given their distinct implementations
for handling fake-overrides.
The commit decreases scope of influence of hacky
`shouldCheckDefaultParams` flag.
^KT-63860 Fixed
Review: https://jetbrains.team/p/kt/reviews/13334/timeline
The previous code was nonsense (I wrote it). It doesn't make sense to
subtract actualOverriddenDeclarations from expectOverriddenDeclarations.
Default parameters are mentioned on the expect side. So default params
in expect/actual supertypes won't be subtracted from
expectOverriddenDeclarations (but should be)
- Pass containingClass (helps to avoid calculations of the
containingClass in allRecursivelyOverriddenDeclarationsIncludingSelf
implementation)
- Reuse allRecursivelyOverriddenDeclarationsIncludingSelf by
DefaultArgumentsInExpectActualizedByFakeOverride &
ActualFunctionWithDefaultParameters
Review: https://jetbrains.team/p/kt/reviews/13244
Review: https://jetbrains.team/p/kt/reviews/13244
Motivation:
```
// Module :lib
class Foo {
val member: Int = 2
}
// Module :app
// dependencies { implementation(project(":lib")) }
class Foo {
val member: Int = 2
}
```
Before the commit:
app_Foo.expectForActual is `null`
app_Foo.member.expectForActual = lib_foo.member
After the commit:
app_Foo.expectForActual is `null`
app_Foo.member.expectForActual is `null`
If I don't fix this problem then
`CommonizerHierarchicalIT.testCommonizeHierarchicallyMultiModule`
becomes red after I fix KT-59887 in the following commits
`app_Foo.member.expectForActual = lib_foo.member` happens because we
also need to match fake-overrides (KT-63550)
I didn't measure it, but theoretically, this commit should be a
performance improvement, becuase we reuse `expectForActual` cache
Additionally, The commit breaks some other tests (e.g.
compiler/testData/diagnostics/tests/multiplatform/headerClass/actualMissing.fir.kt).
The tests will become green again, once I fix KT-59887
Review: https://jetbrains.team/p/kt/reviews/13244
Motivation: Performance. When I fix KT-59887 in later commits, I will
make actual-to-expect resolve to work not only for actual declarations.
Considering that LLFirExpectActualMatcherLazyResolver worked even for
non-KMP projects that might be a potential performance regression
FirExpectActualMatcherProcessor in the compiler does the same thing (it
checks for MultiPlatformProjects before running the transformer)
Motivation: If I don't fix it then I will get a false positive
ACTUAL_MISSING in
DiagnosticCompilerTestFE10TestdataTestGenerated.Tests.Multiplatform.Enum.testSimpleEnum
after I fix KT-59887
The commit also fixes false positive diagnostic in
annotationArgTypeAliasWithArray.fir.kt test
Review: https://jetbrains.team/p/kt/reviews/13244
FirDefaultArgumentsInExpectActualizedByFakeOverrideChecker is an adhoc
checker which can be converted to ExpectActualCheckingCompatibility to
reuse common expect-actual checking infrastructure.
^KT-62913 Fixed
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
Tests that were broken by one of my previous commits are now fixed:
- actualFakeOverride_paramsAreCompatibleViaSharedMethodWithDefaultParams.kt
- inheritedJavaMembers.kt
DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE diagnostic
disappeared in delegation.fir.kt because only one
AbstractExpectActualChecker incompatibility can be reported at a time
(DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE is now reported
not by adhoc checker but by common AbstractExpectActualChecker). It
would be nice to report both of them, but it's a separate issue KT-62631
delegation2 test makes sure that
DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE is reported when
NO_ACTUAL_CLASS_MEMBER_FOR_EXPECTED_CLASS is fixed
This commit fixes fakeOverrides.fir.kt test that got broken in the
previous commit
Previously isFakeOverride was only checked on IR backend. Now this check
is moved to AbstractExpectActualAnnotationMatchChecker which is used by
both: frontend and backend. That's why frontend no longer reports false
positive ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
This tests started failing after the previous commit. I extract this
change into a separate commit to make it obvious that appeared
diagnostics is not an expected behavior. I will fix these tests in the
following commits
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
^KT-63550 Fixed
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
Now it's required to create a new ScopeSession when searching for expect
members for actuals. If you keep reusing actualScopeSession then members
declared in platform may "slip into" the search results, resulting an
incorrect expect for actual (e.g. it happens in
supertypeIsExpectActual_covariantOverrideOfInjectedFromSuper_transitiveSubstitutionFakeOverride.fir.kt)
I suppose that it always has been a bug that we reused
actualScopeSession because we were mixing actualScopeSession and
expect FirSession (which is a bad idea), but we simply didn't have cases
where this bug could be observed. Now after we started matching
fake-overrides, we have such cases.
But creating a new ScopeSession every time is a suboptimal solution. We
need to design a scope caching KT-63773
Review: https://jetbrains.team/p/kt/reviews/13094
I made the test to look like transitiveSuperclassActualization.kt
`actual typealias A = A_J` is incorrect because `A` isn't expect
If I kept the test "as it's", then it would become red once KT-63550 is
fixed
This commit is a preparation step for KT-59887. For now,
expectActualInlineClass.fir.kt became slightly more verbose. Once is
KT-59887 fixed, the verbosity will go away. Because we won't report
incompatibilites mismatches for ACTUAL_MISSING declarations
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
^KT-61955 Fixed
Introduce LV vs don't introduce LV:
introduce LV:
- K1 IDE and K2 project: IDE accurately shows compiler errors
- K2 IDE and K1 project: There are cases when IDE shows red but in reality it's green
don't introduce LV:
- K1 IDE and K2 project: There are cases when IDE shows red but in reality it's green
- K2 IDE and K1 project: There are cases when IDE shows green but in reality it's red
- It became unused after cc70f78027
- And it's not going to become used in the nearest future, since in K2,
we won't have "member scopes" check on frontend (for now)
The cleanup became possible after KT-62590
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
`matchingCompatibilityToMembersMap.allMismatches()` is equivalent to
`ExpectActualMatchingCompatibility.MatchedSuccessfully !in
matchingCompatibilityToMembersMap`
The cleanup became possible after KT-62590
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
incompatibility.allMismatches() always returns true for
mismatchedMembers => hasSingleActualSuspect always returns false =>
filterNot doesn't have any effect
incompatibility.allMismatches() always returns false for
incompatibleMembers => incompatibility.allMismatches() is redundant
Caused by: KT-62590
Now we have the pipeline:
1. Match declarations
2. Run checkers on matched declarations
Since the constructors with empty parameters match we only report
"checking incompatibility" about their incompatible visibility
Before the pipeline introduction, we were running matching and checking
checks together
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
`AbstractExpectActualChecker` works on pairs obtain from
`AbstractExpectActualMatcher` and the last one always returns single
actual for single expect. That's why handling of multiple actuals
doesn't make sense
It became possible to drop it after KT-62590. Now, on a frontend, the
return type check is part of a common AbstractExpectActualChecker logic
Change in nestedAnnotationClassViaActualTypealias.fir.kt aligns the
behaviour with K1. KT-61964
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Those two functions are copy-paste of each other. They diverged since
the time they were copy-pasted. This commit makes
FirExpectActualMatchingContextImpl.areCompatibleExpectActualTypes
up-to-date.
I didn't update ExpectActualUtilsKt.areCompatibleExpectActualTypes
because I will drop it in the next commit.
Change in `dynamicTypesEqualToAnything` doesn't change any logic (yet.
This change in logic will take effect in the next commit), because:
1. `dynamicTypesEqualToAnything` is only changed in
AbstractExpectActualChecker.getCallablesCheckingIncompatibility. But
AbstractExpectActualChecker.getCallablesCheckingIncompatibility doesn't
check return types on frontend (it only check return types on backend).
2. `dynamicTypesEqualToAnything` is ignored on IR backend
I have no idea what is the difference between `createTypeCheckerState()`
and `actualSession.typeContext`, but it aligns these copy-pasted
versions and makes the tests behave like in K1 (at least
'typeUsageWithUnresolvedReference' and 'kt57320' are affected)
This commit is mainly a preparation for the next commit.
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
- getCallablesStrongIncompatibility is unused (because it moved to the
"matcher" KT-62590)
- `checkClassScopesCompatibility` parameter is always `true` or unused
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
- Migrate ExpectActualCompatibility -> ExpectActualCheckingCompatibility
where the "checker" is expect
- Migrate ExpectActualCompatibility -> ExpectActualMatchingCompatibility
where the "matching" is expect
KT-62590 in progress. A lot of tests start to fail now. I will fix them
in next commits
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
- The Matcher must only do the "matching" (aka "strong compatibility")
- Drop all "checking" related (aka "weak compatibility" related) logic
- `checkClassScopesCompatibility` parameter belongs to the
"expect-actual checker" not to the "expect-actual matcher". Drop it
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
This is a minor optimization.
This commit is a step forward for KT-62590
Conceptually, `checkClassScopesCompatibility` belongs to the
"expect-actual checker". It doesn't belong to the "expect-actual
matcher".
- `checkClassScopesCompatibility` should be set to `true` when you want
to do the "checking"
- `checkClassScopesCompatibility` should be set to `false` when you want
to do the "matching"
`collectActualCallablesMatchingToSpecificExpect` only needs the
"matching"
No tests changed their behaviour
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
1. Support variance in ErrorListDiagnosticListRenderer.
I will make some diagnostics to have covariant type arguments in the
next commits
2. Drop unused code
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Motivation: Make getCallablesCompatibility API slightly nicer. The
function is going to be called from more places after KT-62590 is fixed.
This commit makes fixing KT-62590 easier
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
It should have been WeakIncompatible from the beginning because it's not
possible to overload by return type in Kotlin
This commit is a step forward to fix KT-62591
Unfortunately, the test cannot demonstrate the problem because of
another bug in K2 KT-59887
^KT-62752 Fixed
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Motivation:
It makes expect-actual matching-checking model more consistent.
expect-actual "matching" is run before FirResolvePhase.BODY_RESOLVE. You
can't know return types, until you run BODY_RESOLVE. That's why the
return type can't be checked during expect-actual matching. But it's
cursed: you have something that have to match by, but, at the same time,
you can't do it.
expect-actual "checking" is run after FirResolvePhase.BODY_RESOLVE.
That's why if we convert ReturnType incompatibility to WeakIncompatible
(which should have been called CheckingIncompatible), then expect-actual
matching model becomes consistent.
We will also be able to get rid of unnecessary
FirActualCallableDeclarationChecker. Because it won't be necessary.
Return types will be checked by common logic of expect-actual "checker"
^KTIJ-27522 Fixed
It's the only reasonable behavior for this API in it's current shape
(when it returns a list of declarations)
It's a common mistake to take only Compatible from
expectActualMatchingMap. The problem will be gone after I fix KT-62590
Motivation to fix this bug, is because it will be easier for me to split
expect-actual matcher-checker-monster thing KT-62590
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
Motivation: I'm going to drop NonPrivateCallableAdded (KT-62655) in the
next commits. But I don't want to change the existing logic when I drop
it. That's why I have to introduce the "Unknown" case
^KT-62656 Fixed
I blindly converted all `@AllowDifferentMembersInActual` to suppresses.
But some suppresses in stdlib are redundant. I'm too lazy properly
annotate only the necessary places. All these suppresses will go away
after the bootstrap update anyway
I drop allowDifferentMembersInActual_class and
allowDifferentMembersInActual_typealias tests because their only purpose
was to check that `@AllowDifferentMembersInActual` works as expected
Note: some tests are failing in the compiler because of that. I will fix
them in the next commit
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation: make sure that cases like KT-62027 won't happen again
Review: https://jetbrains.team/p/kt/reviews/12279/files
Now it's responsibility of the
`createExpectActualTypeParameterSubstitutor` calller to think about the
case when parameters size isn't equal. You must not be able to create a
substitutor if type parameters sizes are not equal
Improvement in `createExpectActualTypeParameterSubstitutor` API also
improves
`AbstractExpectActualCompatibilityChecker.getCallablesCompatibility`
API.
Because suppose that you accidentally created a redundant wrapping
substitutor => you need to handle the case of not equal type parameters
size on the call site => you start thinking why you should do that on
the call site? It must be a responsibility of
`getCallablesCompatibility` => you realize that you created a redundant
wrapping substitutor
When type parameters size doesn't match, it's better to pass `null`
instead of a parentSubstitutor. Before this commit we were creating an
invalid substitutor. Who knows what can go wrong because of that further
along the execution
Related issue: KT-54827
Related test: compiler/testData/diagnostics/tests/multiplatform/kt54827.kt
Review: https://jetbrains.team/p/kt/reviews/12279/files
Motivation for the commit: There is no user report or anything. It's not
known whether these invalid substitutors were causing problems. I just
noticed this problem while doing substitutor API refactoring (see the
next commit).
Note: `ExpectedActualResolver.matchActualCallableAgainstPotentialExpects`
has the same problem. But since it's K1 I won't touch it
This commit is literally this shell command:
```
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/AbstractExpectActualAnnotationMatchChecker.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1AbstractExpectActualAnnotationMatchChecker.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/AbstractExpectActualCompatibilityChecker.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1AbstractExpectActualCompatibilityChecker.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/ExpectActualCollectionArgumentsCompatibilityCheckStrategy.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualCollectionArgumentsCompatibilityCheckStrategy.kt
cp core/compiler.common/src/org/jetbrains/kotlin/resolve/multiplatform/ExpectActualCompatibility.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualCompatibility.kt
cp compiler/resolution.common/src/org/jetbrains/kotlin/resolve/calls/mpp/ExpectActualMatchingContext.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualMatchingContext.kt
cp core/compiler.common/src/org/jetbrains/kotlin/resolve/multiplatform/ExpectActualMemberDiff.kt compiler/resolution/src/org/jetbrains/kotlin/resolve/multiplatform/K1ExpectActualMemberDiff.kt
```
Motivation: KMP is going to evolve in K2 a lot. But we don't want to
touch K1 version of KMP. That's why it's easeir to just copy-paste
expect-actual matcher into K1 flavor
^KT-62027 Fixed
`getCallablesCompatibility` requires parentSubstitutor as a parameter,
but we created a member-level substitutor
`getCallablesCompatibility` will create member-level substitutor itself,
no need to create member-level substitutor on the call site.
IndexOutOfBounds was happening in an attempt of creating member-level
substitutor
I will refactor the `createExpectActualTypeParameterSubstitutor` API in
the following commits later. It will help to avoid problems like that
Nikita Bobko