- 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
This makes sense because this mode is the default in the production
compiler. Forgetting to enable it where necessary led to different
bizarre test failures, see for example changes around 3fee84b966 and
KT-34826
The kotlin-scripting-compiler-impl jar is used in the idea plugin and
therefore should not depend on the cli parts of the compiler to avoid
dependency from the plugin to the kotlin-compiler.jar.
Therefore the cli-dependent parts were moved to the scripting plugin
jar, which is used only in cli compiler based environments.
Also implement required abstractions to allow this movement and
drop some redundant dependencies to the cli parts in other projects.
PSI-based implementation (accessible via
`-Xuse-old-class-files-reading`) loads parameter names from the
"MethodParameters" attribute if it's present, so our own implementation
should as well.
This metadata doesn't seem supported in the java.lang.model.element API
though, so SymbolBasedValueParameter (which is used in `-Xuse-javac`)
will continue to have incorrect behavior for now
#KT-25193 Fixed
This allows to get rid of the dependency on descriptors.runtime from
compiler/IDE tests which is problematic: classes there clash with the
classes in kotlin-reflect, which reference declarations in shadowed
packages
Only top-level types on fields, methods' return types and
value parameters are supported to catch-up how class-files are loaded
in IntelliJ (see IDEA-153093)
NB: this commit also affects
ForeignJava8AnnotationsNoAnnotationInClasspathWithFastClassReadingTestGenerated
that were failing before
#KT-20016 Fixed
The main reasoning for the module is to avoid running any compiler tests while executing run configuration that searches tests across module dependencies.
Dmitriy Novozhilov