This parameter accepts the name of the "mode" in which the partial linkage would work. Currently, only two options are supported: 'enable', 'disable'. But the list may be extended in the future as needed.
At the moment the 'disable' option is the default one. This will be changed in #KT-51447, #KT-51443.
If the compiler runtime JDK is 9+,
it will already contain JrtFileSystemProvider and won't use provided
classloader
In order to fix KT-57154 we need to provide "java.home" argument to
newFileSystem
In order to reduce the severity of the leak in KT-56789 we cache
instances of FileSystem itself forever
Otherwise, each invocation of newFileSystem on JDK 9+ will leak
classloader, which is created deep inside the JDK code
Add unit test for JRT-FS contents served through CoreJrtFs
Add Gradle Integration test to
test if the daemon correctly reads JDK contents from the specified
toolchain and not from its runtime JDK
^KT-57154
Regression test for ^KT-57077
1. Leaving no unbound symbols in the IR tree, KT-54491:
- All unbound symbols are bound to synthetic stub declarations
- Improved detection of the root cause for every partially linked classifier
- Improved error messages
2. Visibility valiation, KT-54469
3. Always check deserialized symbols:
If the deserialized symbol mismatches the symbol kind at the call site in the deserializer then generate and reference another symbol with the same signature. In case PL is off, just throw IrSymbolTypeMismatchException.
4. Handle class inheritance violation:
- Detect illegal inheritance (ex: inheriting from a final class)
- Detect invalid constructor delegation (ex: delegating to another class than the direct superclass)
- Simplification: Reduce the number of PartialLinkageCase subclasses
- Reworked error message generation to have shorter and clearer messages
5. Handle class transformations and all known side-effects, examples:
- nested <-> inner
- class <-> enum/object
- adding/removing subclasses of sealed class
- adding/removing enum entries
6. Check direct instantiation of abstract class.
Such instantiation could be possible if a class was non-abstract in the previous version of a library.
7. Handle unlinked annotations on declarations.
Such annotations are removed from the IR. The appropriate compiler error message is produced for every individual case.
8. Handle value argument count mismatch at call sites
9. Handle calling suspend function from non-suspend context.
This could happen if a suspen function was non-suspend in the previous version of a library.
10. Handle overriding inline callables.
Only the leaf final callable can be marked with `inline`.
11. Detect illegal non-local returns from noinline/crossinline lambdas.
Those classes mainly include KotlinCoreEnvironment and its dependencies
This change is needed for two reasons:
1. Splitting of some common configuration of compiler from logic of CLI
makes code structure more clean
2. There is a need to add dependency on `:analysis:analysis-api-standalone`
to `:compiler:cli`, because FIR analogue of AnalysysHandlerExtension uses
services from it. But the problems is that standalone AA itself depends
on classes for compiler configuration, which leads to circular
dependency between those modules. Extracting configuration to
`:compiler:cli-base` solves the problem
This is a low-level extension point for Kotlin/JVM, which is supposed to
be used instead of ClassBuilderInterceptorExtension.
#KT-54758 Fixed
#KT-56814 Fixed
#KT-57117 fixed
also:
- refactor the position finder (mostly for testability)
- add testing of position finder to the testLightTreeReadLineEndings
- refactor the test for readability
- add mixed line ending scenario
Normally, 'DefaultErrorMessages' extensions should only be loaded
from the main compiler JAR. However, in the in-process JPS build,
there are two versions of the compiler classes in the process, and
'ClassLoader's there are not fully isolated.
'ServiceManager' loads extensions from both 'META-INF' locations. If
the JPS plugin bundles newer compiler components, newly appeared
'DefaultErrorMessages' extensions will be loaded from the JPS (parent)
'ClassLoader', causing an exception.
Such a problem appeared with 'DefaultErrorMessagesWasm':
- - - - -
java.util.ServiceConfigurationError:
org.jetbrains.kotlin.diagnostics.rendering.DefaultErrorMessages$Extension: org.jetbrains.kotlin.wasm.resolve.diagnostics.DefaultErrorMessagesWasm not a subtype
- - - - -
The previous changes to the disposer registration changes introduced a
weird problem exposed in the Gradle (test?) environment, that caused
a performance regression - it seems that keep alive system property
in that setting was cleared at the time the disposer was called, causing
app env disposal when keeping it alive was expected.
This fix captures property value at the moment of disposer registration,
making it similar in that respect to the previous variant and avoiding
the performance degradation.
#KT-56992 fixed
CoreJrtFileSystem uses JrtFileSystemProvider provider to read contents
of jrt-fs from JDK
Implementation of FileSystems.newFileSystem causes metaspace memory leak
that wasn't fixed until JDK 17, see
https://bugs.openjdk.java.net/browse/JDK-8260621
When FileSystems.newFileSystem used to create jrt-fs on JDK9 with
provided java.home value it creates new ClassLoader under-the-hood,
which subsequently leaks due to aforementioned bug
Remove conditional usage of `java.home` + FileSystems.newFileSystem and
switch to use jrt-fs classloader cache regardless of
compiler runtime JDK to reduce classloader leaks
^KT-56789
If a developer interrupts (kill gradle process) a compilation process or
an internal error interrupts the compilation process,
the incremental cache files may be corrupted.
The patch creates a special guard file, which allows detecting
if the previous compilation was not successful,
and in case of any issues drops the incremental cache files.
^KT-56581 Fixed
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
Scope for incremental compilation refers to binaries from previous step
of IC. It is used not only in IC context itself, but also it is
subtracted from original libraries scope. Before previous commit there
was such scheme:
1. create incremental compilation context for files of specific session
2. subtract IC scope from main libraries scope
3. use updated libraries scope to create library session
4. create all needed source session(s)
So here was a side effect of creating new IC context, which
1. is smelling code, because it increases mind complexity
2. hard to implement with new session utilities
So to fix this problem this commit changes the scheme above:
1. create IC scope and modify libraries scope
2. create libraries session
3. create source session(s) and IC context for them
Dmitriy Novozhilov