- 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
We should use PsiLiteralExpression instead of PsiLiteral as it
is used in the Java world. Effectively, `psiLiteral` property
already has this type (as `createPsiExpression` produce `PsiExpression`),
but we missed this part before and used just PsiLiteral for our
own class
^KT-63949 Fixed
- Make the messages that are reported by KLIB resolver prettier
- For those messages that affect the resolve process add
prefix "KLIB resolver: "
- Don't log warning on duplicated libraries on the classpath. This
does not make any sense.
^KT-63573
Marco Pennekamp