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
The only test that fails without is FirOldFrontendLightClassesTestGenerated.
While there's no proof that code fails in production, the footprint from
services shouldn't be big, and it's better to have them instead of
failing in runtime.
KTI-1114
The patch adopts and reuses the optimizations from the legacy backend.
The optimizations remove useless temporary variables,
statements and simplify generated JS code.
The optimizations can be disabled by `-Xoptimize-generated-js=false`.
Related to KT-51139
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)
```
Using of Kotlin reflection for simple operations like bean management is very slow
First time initialization time: 261 ms for `copyBean(K2JVMCompilerArguments())`
Subsequent calls of `copyBean(K2JVMCompilerArguments())` take 1.7 ms per call
Unfortunately compiler argument handling is also used in Kotlin IntelliJ plugin
to parse facet settings. Big projects may have thousands of Kotlin facets
The same `ArgumentUtilsKt.copyProperties` frame is seen across various freezes:
IDEA-252440 2-3 minutes freeze on Kotlin project reimporting in last 203 eap
IDEA-253107 A lot of short freezes (1-3 sec) during Kotlin project development
KTIJ-23501 Make main run configuration detection lighter
KTIJ-22435 Unresponsive UI with 100% cpu
Reflection issue:
KT-56358 KClasses.getMemberProperties takes too much time
This commit replaces all reflection stuff with a simple code generation
Now `K2JVMCompilerArguments().clone()` goes to hard-to-measure time
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
Alexander Udalov