- For each test, `ReplCompilerJava8Test` effectively created two
environments: one in `setUp` for pre-compilation and one in `runTest`
managed by `GenericReplCompiler`. The `setUp` environment is unshared,
so it wasn't the same as the one managed by `GenericReplCompiler`.
Because the `setUp` environment was registered with
`testRootDisposable`, its application and project were effectively
disposed at the end of the test, together with the other environment.
- Adding a call to `resetApplicationManager` to
`KotlinCoreEnvironment.disposeApplicationEnvironment` in a previous
commit caused `ReplCompilerJava8Test` to fail with the following
sequence:
1. At the end of a test, `testRootDisposable` is disposed.
2. The project count disposable registered in
`getOrCreateApplicationEnvironment` is disposed first. This causes
the shared application's project count to go to 0 and triggers its
disposal via `disposeApplicationEnvironment`.
3. In `disposeApplicationEnvironment`, the application manager's
application is reset to `null`.
4. The disposer continues with disposables which were registered for
the `setUp` environment initially. One of these is
`PsiManagerImpl`, which disposes `FileManagerImpl`, during whose
disposal `ApplicationManager.getApplication()` is called. Since the
application was reset, it is now `null` and an NPE occurs.
- The solution disposes the `setUp` environment early so that it cannot
clash with the shared environment from `GenericReplCompiler`.
^KT-64099
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
So, we're slowly getting rid of the hack with LATE_JDK_SIGNATURES
which is necessary because there's no freshest JDK available at
build agents.
But hope, it would be removed once JDK 21 is there (see KT-58716).
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
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
This commit includes:
- test runners for foreign annotation tests
- minor changes testdata related to changed directives syntax
- dropping tests with javac integration: old javac tests actually ran
compiler without javac because of bug in configuration, so some
nullability annotations features are not supported in javac mode.
It's fine to drop it since javac mode is not fully supported
by compiler
This is needed to provide ability for declaring new implementations of
test generators, based on existing infrastructure, which won't add
dependency on :compiler:tests-common
Also this commit removes implicit dependency on :compiler:tests-common
from :compiler:tests-common-new
Otherwise behavior might change because enhancement may force computation
for other type parameters in cases like:
class A<X extends Y, Y extends X> {}
See the test:
org.jetbrains.kotlin.checkers.DiagnosticsTestGenerated.Tests.J_k#testRecursiveRawUpperBound3
Dmitriy Novozhilov