IrMangledNameAndSignatureDumpHandler can dump either signature mangled
names by Fir or by descriptors, but not both at the same time. And
mangled names should be equal to preserve ABI compatibility.
^KT-57788
- 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
- The incremental configuration for JS recompilation tests creates its
own test root disposable. It needs to be properly handled to avoid
disposable leaks.
- The incremental configuration's disposable is registered with the
parent configuration's disposable because it lives in its scope and
should thus not be a root disposable. It's also disposed at the end of
`transform` because the incremental configuration's lifetime ends
there.
^KT-64099 fixed
- `testDisposable` is already managed by `KtUsefulTestCase`, so disposal
support comes for free. This replaces the previous `TestDisposable`,
which was never disposed properly.
^KT-64099
- This helps to track down disposables which are never disposed, and
reduces confusion when printing disposables in general (the names will
now be meaningful, instead of endless lists of "newDisposable" and
"TestDisposable").
^KT-64099
- The disposable passed to `getOrCreateApplicationEnvironment` should
not actually be the application environment's disposable, which is
created inside the function. Instead, it should be the project's
disposable, which is used to track how many projects still rely on the
shared application environment.
- This issue wasn't apparent before because there is no visible
consequence when an application isn't disposed after all projects have
been disposed (during tests). However, the solution for KT-63650
relies on application environments being disposed after all projects
are disposed, so that a new application environment with a different
configuration can be created. (Only one shared application environment
may be active at the same time.)
^KT-63650
This check is used in equivalence check which is symmetric, and
java refers to kotlin through light classes.
LC implementation already contains support for matching
wrapped and origin kotlin members,
both K1 and K2 LC implementations.
Thus, this check is redundant.
Removing it, we cleanup kotlin psi from java psi
In fact, TopDownAnalyzerFacadeForJVM.createContainer initializes the
whole K1 frontend. While it is only used to create a module descriptor
for GenerationState.Builder, in real K2 compiler the module descriptor
would be created via irModuleFragment.
See org.jetbrains.kotlin.cli.jvm.compiler.pipeline.CompilerPipelineKt.generateCodeFromIr
Sergej Jaskiewicz