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
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"
...in `ACTUAL_ANNOTATIONS_NOT_MATCH_EXPECT` diagnostic message.
Unlike in previous commit, this can't be fixed right in
`FirSymbolRenderer`, because `ConeIdRendererForDebugging` renders
differently and a lot of lazy resolve tests rely on that.
^KT-62585
It shouldn't break existing usages, because
1) default `ConeIdRendererForDebugging` renders ClassId in
same way as before the change;
2) I didn't find any usages, which use non-default idRenderer,
but rely on full ClassId be rendered for qualifiers.
^KT-62585
Unresolved annotation arguments were treated as absent arguments,
which lead to false-positive reports.
Add assert and test for that and fix.
MR: KT-MR-12245
^KT-60671 Fixed
This includes checking of annotatins set on:
- value parameter types
- type parameter bound types
- extension functions receiver types
- function return types
- class super types
Fix in `defaultParams_inheritanceByDelegation_positive.kt`
is needed because of problem in resolution of implicit return types
(KT-62064), which leads to crash in annotation checker, because it
expects resolved return type.
MR: KT-MR-12245
^KT-60671 Fixed
Test for the case when enum entry has constructor call but doesn't have
body already exist in
`compiler/testData/diagnostics/tests/multiplatform/enum/constructorInHeaderEnum.kt`.
^KT-59978 Fixed
Roman Efremov