If the right-hand side of an equality comparison contains an assignment
to the variable used in the left-hand side, then implications about the
equality comparison within data-flow analysis cannot be applied, as the
value of the variable will be different after the comparison.
^KT-55096 Fixed
that causes flaky tests because the default positioning strategy
was dependent on the order of the reported messages.
The code led to it was introduced in an attempt to extract common
PSI-independent strategy because PSI is leaking into the abstract
diagnostic infrastructure. The approach is definitely problematic,
but to fix it now, the leaking dependency to the psi-based module
is introduced. This should be fixed in the future by introducing
better abstractions.
Fixes flaky tests touched in the commit.
#KT-63002 fixed
This test can be used to make small performance measurements of
the core commonizer on occasional basis. This test is not intended
for regular execution, e.g. at the CI server.
^KT-63159
"data objects" is only available since language version 1.9. But we should not use LV 1.9, because it is used in the Gradle build classpath and would be incompatible with Gradle Kotlin runtime.
Then only manually override equals/toString/ works here.
#KT-61657 Fixed
Merge-request: KT-MR-12759
Merged-by: Dmitrii Krasnov <Dmitrii.Krasnov@jetbrains.com>
- KT-62397 occurs in the IDE because enum entry symbols from libraries
are deserialized from stubs, which currently produce
`FirFromMissingDependenciesNamedReference`.
- During opt-in usage checks, the compiler only considered resolved
references when getting the severity name, but we can just take the
name from the `FirFromMissingDependenciesNamedReference`.
^KT-62397 fixed
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
Deduplicate Fir2IrExtensions creation and move the
convertToIrAndActualizeForJvm function to 'cli', which allows to remove
the dependency of 'fir.entrypoint' on 'backend.jvm'.
Note that behavior slightly changes in IncrementalFirJvmCompilerRunner:
previously the value of linkViaSignatures was always false, now it is
taken from the compiler configuration, which seems more correct.
Brian Norman