In the vast majority of tests, diagnostics are reported at a slightly
different location in LT vs PSI. This is because in the light tree mode,
backend errors are reported basically on the start of the IR element,
which is for example the keyword "class" for a class and not its name as
in K1 or in K2+PSI. Similarly, the end of the diagnostic is at the
ending offset of the IR element.
Normally it would be a bit user-unfriendly to highlight the whole class
as red, starting from the keyword "class" and ending with the closing
brace "}". But remember that these are backend diagnostics in the K2+LT
mode, which is only possible in the compiler scenario, not in the IDE.
And in this case, the ending offset doesn't matter at all because it's
not presented to the user, and minor change in the starting offset is
not a problem as well.
There are some tests which legitimately fail in the LT mode because the
corresponding diagnostics haven't been supported. They will be dealt
with in subsequent commits:
testPropertyInlineCycle
testInlineCycle
MultifileClasses.testJvmSynthetic
testSuspendInlineCycle
testIndirectInlineCycle
#KT-59586
Add some more filters on private/synthetic stuff (which doesn't matter
in practice) to make full and light analysis mode dumps as similar as
possible, so that all existing tests will pass for JVM IR. Unmute some
tests which were failing with the old JVM backend.
Tests on repeatable annotations are muted because in full analysis,
annotations are wrapped into the container (e.g. `@A(1) @A(2)` ->
`@A$Container(A(1), A(2))`), but they are no in the light analysis mode.
So there's always going to be a difference for these tests between full
and light analysis, unless we're going to change behavior of kapt, which
would be a kind of a breaking change.
#KT-58497 Fixed
According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
After it's released, there would be no need in them, but right now
they are unavailable through the toolchain, so we can't require it.
See KT-58765 for tracking
But there should be a dedicated Build configuration with JDK_21_0 env
properly set.
^KT-58716 Fixed
We've muted some irText tests on JS in the previous commits because
test expectations in some tests are different when targeting JS.
AbstractKlibJsTextTestCase tests use a different logic:
they compare the dump of the deserialized IR with the frontend-generated
IR, not with the expectations in text files, thus muted tests weren't
actually failing.
Here we introduce a temporary fix, namely
a separate // IGNORE directive for klib tests.
When klib tests are moved to the new test infrastructure, there will be
no need to do this.
Now all tests with `Fir` in name are named accordingly to parser which
is used in them -- `FirPsi` or `FirLightTree`. This is needed to keep
consistency between different types of tests, because there is no
single default in parser mode between different scenarios of using FIR
- `.ll.kt` test data can be added in cases where LL FIR resolution
legally diverges from K2 compiler results.
- Each `.ll.kt` test is prefixed with an `LL_FIR_DIVERGENCE` directive
which must explain why the test may diverge from K2 compiler results.
- `LLFirDivergenceCommentChecker` ensures that each `.ll.kt` file
contains an `LL_FIR_DIVERGENCE` directive.
- `LLFirIdenticalChecker` results in an assertion error if the `.ll.kt`
test and its base test are completely identical, including in their
meta info (but ignoring `LL_FIR_DIVERGENCE`).
- The checker additionally ensures that the base source file and the
`.ll.kt` source file have identical Kotlin source code (ignoring
meta info and `LL_FIR_DIVERGENCE`). This ensures that both tests
test the exact same thing.
- `.ll.kt` files are ignored by select test generators, in addition to
`.fir.kt` files.
This test uses a hacky mode of the compiler which is not worth it to
support further (especially in K2), `USE_SINGLE_MODULE`, where
everything is compiled in one module. The purpose of the test is just to
check that metadata for local/anonymous classes is written correctly.
So we can replace it with the tests on kotlinp, which uses
kotlinx-metadata-jvm and dumps all loaded metadata to text.
This replacement is not perfect, in particular because it won't check
that the reflection machinery is able to load this metadata, and because
it won't check that annotations are loaded correctly from the bytecode.
But IMHO it's good enough, there are box tests on reflection on local
classes (e.g. `reflection/annotations/localClassLiteral.kt`), so this
way is better than having to support the weird compiler mode for just
one test.
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
These tests used the old type inference constraint system, so it didn't cover the current compiler logic almost at all
It'd be fine to implement similar test for the new type inference constraint system
^KT-52699
Dmitrii Gridin