The trove4j library is licensed under LGPL, and that causes some troubles while working with it. The fastutil library provides the same functionality in the context of our needs, and is licensed under the Apache license.
^KTI-1135 In Progress
Makes it easier to introduce a Gradle property for configuring
IncrementalCompilerRunner.
^KT-64513 Fixed
^KT-63837 In Progress
Merge-request: KT-MR-13671
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
- 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
Previously, the validation was that the port is within the [1, 65535) range. Considering the defined range [17001, 18000) for the random port selector, it makes more sense to check that range instead.
A few messages were improved:
* If the daemon process died at the startup, add its last 10 lines of the output to the log and report to the EXCEPTION (ERROR in the case of Gradle) level
* If some exception occurs during connection attempt, add its stacktrace and report to the EXCEPTION (ERROR in the case of Gradle) level
* Added more DEBUG level messages
* Some important messages are moved to the INFO level
* Added a suggestion to report issue to kotl.in/issue
^KT-55322 Fixed
Before this change, the logic was to find the most suitable daemon and try connecting to it in a loop, ignoring the fact that it could be dying. Now, instead of trying to connect to the daemon dying daemon in a loop, we will make only 1 attemp and then skip if it's already dying.
^KT-55322 In Progress
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
Collecting 'moduleInfo' is required for the old history-file-based
incremental compilation approach. And the way how it is being collected
violates Gradle project-isolation feature as it accesses all Kotlin
compile tasks from other Gradle subprojects.
When the new IC based on classpath snapshot is enabled, the plugin will
not collect 'moduleInfo' making it compatible with project isolation.
^KT-59826 Fixed
IC caches often contain file paths. To make them relocatable, we need
to convert these file paths into relative paths, relative to a base
directory.
- If the file paths are source files, we can use the root project
directory as base.
- If the file paths are class files, we should use the classes
directory as base (before this commit, we used the root project
directory in both cases, that's why we hit KT-58547).
The key changes in this commit include:
- RelocatableFileToPathConverter: converts paths to relative paths
- IncrementalCompilationContext: contains 2 different path converters,
one for source files and one for class files
- SourceToOutputFilesMap: maps source files to class files using the
above path converters
- IncrementalCompilerRunner: creates the path converters based on file
locations
Test: RelocatableFileToPathConverterTest unit test
SourceToOutputFilesMapTest unit test
BuildCacheRelocationIT.testCustomBuildDirectory integration test
^KT-58547 Fixed
1) Move root util functions to separate CompileRunnerUtils file from IncrementalJvmCompileRunner to leave the only class instance there and to separate util functions
2) Move TestLookupTracker from the abstract parent class location to a separate file as an implementation class
3) Small change naming of building functions just to clarify what they do
4) Some small code-style refactorings
It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
Review: https://jetbrains.team/p/kt/reviews/9562
This commit fixes IdeaJsr223Test in kotlin plugin. The test failure was
caused by b50a803b6f commit where we
dropped `put(JVMConfigurationKeys.JDK_HOME, ...)` from
`configureJdkClasspathRoots`. Ilya Chernikov says that it's incorrect to
set JDK_HOME in `configureJdkClasspathRoots`.
To reproduce the test failure:
1. Update `.idea/libraries/kotlinc_kotlin_dist.xml` and
`.idea/libraries/kotlinc_kotlin_jps_plugin_classpath.xml` with new
Kotlin (in other words: bump bundled JPS)
2. Run the test
Test failure stacktrace:
```
javax.script.ScriptException: error: cannot access 'java.io.Serializable' which is a supertype of 'kotlin.Int'. Check your module classpath for missing or conflicting dependencies
y.first() + 2
^
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.asJsr223EvalResult(KotlinJsr223JvmScriptEngineBase.kt:104)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.compileAndEval(KotlinJsr223JvmScriptEngineBase.kt:63)
at org.jetbrains.kotlin.cli.common.repl.KotlinJsr223JvmScriptEngineBase.eval(KotlinJsr223JvmScriptEngineBase.kt:31)
at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
at org.jetbrains.kotlin.idea.repl.IdeaJsr223Test.testJsr223Engine(IdeaJsr223Test.kt:31)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at junit.framework.TestCase.runTest(TestCase.java:177)
at com.intellij.testFramework.UsefulTestCase.lambda$runBare$11(UsefulTestCase.java:479)
at com.intellij.testFramework.UsefulTestCase.lambda$wrapTestRunnable$13(UsefulTestCase.java:500)
```
Historically flag was enabled for Gradle projects, but we don't have fir-based JavaTracker for the K2 compiler for now, so we need to use a fallback strategy.
Note: it was disabled for tests with K2
Note2: after adding a fir-based java classes tracker this value should be set to true (KT-57147)
#KT-56886 Fixed
Merge-request: KT-MR-9053
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
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).
Do not recompute children on each file request
At the same time, we should clear the roots after each compilation
just the same way as we do for common jars
- add FastJarFS cache cleaning to the daemon implementation, so
the behavior is now the same as for CoreJarFS
- clear not only mappings but also handlers cache: this may result some
slowdown on comparison with the previous cleaning implementation,
but should avoid unreliable behavior on heavy parallel build usages.
Dmitrii Gridin