^KT-58765
Now that JDK 21 was released as stable, we can remove separate test
configurations for testing the compiler with JDK 21 and reintegrate
the corresponding test data into standard test configurations.
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
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
This will be used for two purposes:
1) call lowerings and codegen separately from
KotlinToJVMBytecodeCompiler to support cyclical module dependencies
(KT-49575)
2) split lowerings and codegen into separate modules
Since IDEA moved most of it's jars to java 11 it's illegal to use them
in our dependencies, so all modules which use `intellijDep()` should
carefully specify which jars they use
Together with extracting codegen to a separate (unrelated) module in the
future, hopefully it'll speed up the build of JVM IR by making it more
parallel, and helping incremental compilation to avoid recompiling code
that depends on lowerings because of `implementation` dependency.
Add a new module 'backend.jvm.entrypoint' which depends on psi2ir and
contains code that runs psi2ir + JVM IR backend with serialization
implementations.
Hopefully this will allow to compile these modules in parallel and
reduce the build time.
This is needed because now we have different tests modules with different
test frameworks (JUnit3 and JUnit5) which has no dependencies between
each other. So for keeping all test generation config in one place
we need module which may rely on all independent test modules
There is an a optimization in our `projectTest` config which filters
out some compiled test classes if they didn't contain specified test
(if user ran :test task with --tests flag). This optimization for one
tests left only one .class file which contains test. But JUnit 5 for
tests in inner classes (with @Nested annotation) requires not only
target class, but and all it's containers
Test: package.SomeTest$Nested.testMethod
JUnit4: package/SomeTest$Nested.class
JUnit5:
- package/SomeTest.class
- package/SomeTest$Nested.class
All of new classes lays in lays in :compiler:tests-common-new module
which includes classes for FE 1.0 and FIR diagnostics tests and
JVM black boxtests
Sergej Jaskiewicz