^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
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
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)
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)
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
There are still some places in `.fir.kt` where false-positive reports
remained. This is because of IR checker, which will be fixed in next
commit.
^KT-31636
After previous commits IrActualizer runs only there are at least two modules
in backend input. So to check diagnostics from Actualizer all tests
should contain at least two modules
Diagnostics in test `extendExpectedClassWithAbstractMember.kt` were
changed because there is an exception from IrActualizer caused by
errors from frontend (`ABSTRACT_METHOD_NOT_IMPLEMENTED`), which is
swallowed by this kind of tests
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
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
It is duplicated because we have two checkers: FIR (for IDE support
in simple cases) and IR ("honest" checker supporting all cases).
Fix this by running FIR checker only in IDE.
FIR checker behavior remains covered by tests in
`LLFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated`.
^KT-62559 Fixed
Updated tests contain errors which are incompatible with fir2ir conversion
(like `PACKAGE_OR_CLASSIFIER_REDECLARATION` and `EXPECT_AND_ACTUAL_IN_THE_SAME_MODULE`),
so running fir2ir on such code may lead to exceptions
for `ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT` checker near to
other tests of this diagnostic. It is fine to move it out of
`multiplatformCompositeAnalysis` dir, because, actually, it tests
the case with comparison of FirAnnotationCall and FirAnnotationImpl,
which doesn't require composite analysis mode.
^KT-62559
...`ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT` checker near to
other tests of this diagnostic. This is because now such tests
are run in lazy resolve test suite, so no need to store them
separately.
^KT-62559
It is expected, that in some complex cases
`ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT` reports in .ll.kt disappeared
at all. This is because FIR checker doesn't catch comlex cases,
which are handled by IR checker.
Also add comments about bugs KT-62886 and KT-63382 found by tests.
^KT-62559
New tests are red in current commit!
All `.ll.kt` files are just copies of `.fir.kt` or `.kt`. This will be
fixed in the next commit to clearly show difference between LL and FIR.
The original purpose of this change was to test
`ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT` diagnostic, for which FIR checker
will be run only in IDE (to be changed in next MR), so its reports
a lost from usual KMP tests.
But this looks like a useful change for all KMP tests, not only this
diagnostic.
^KT-62559
This is needed to be able to implement creation of unbound symbols
for references of corresponding declarations (KT-62856)
There was an exception from FIR2IR that was fixed with this change,
so fir2ir test SuperClass started to pass along with IrActualizer,
which reported some new errors
This is needed to be able to implement creation of unbound symbols
for references of corresponding declarations (KT-62856)
There was an exception from FIR2IR that was fixed with this change,
so fir2ir test expectDeclarationWithWeakIncompatibilities started to
pass along with IrActualizer, which reported some new errors
The relative path of a test file is just its name, even if it's in a
module.
Diagnostics in IR are mapped to the file path and so it's reported on
all files with the same path, i.e. name.
This doesn't happen in production code because no two files can have
the same path.
The proper fix would be to prefix the test files' paths with the module
name.
Unfortunately, this breaks a bunch of test runners that rely on the
current behavior.
Especially, some JS runners turned out to be hard to fix.
The linked YouTrack issue contains a WIP, incomplete patch of fixing
some runners.
#KT-61592 Fixed
#KT-63252
^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 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
Nikita Bobko