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.
since implicit imports are used in the gradle scripts, where it seems
difficult to precisely control list of import to avoid
unresolved names. And we can relatively safely ignore
unresolved imports there
#KT-62404 fixed
#KT-62305 fixed
NB: kotlin reflection do not see script class constructor after
this change, and it's ok, since the fact that the script is compiled
into a class is an implementation detail.
If needed, java reflection could be used to access the constructor.
Nikita Bobko