According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
The
`IncrementalJsFirKlibCompilerWithScopeExpansionRunnerTestGenerate
.testSerializedSubClassAndChangedInterfaces`
test fail because the checksums of
the `manifest` files don't match
after the full recompilation.
It happens, because the `b.kt` file may be passed
to the compiler before `a.kt`, in which case while
generating the data class members the compiler
will generate a call to `Any::hashCode` when
accessing the hashcode of the `a` property instead
of generating a call to the fake override
`A::hashCode`.
When working with PSI, the compiler sorts the
input files to at `KotlinCoreEnvironment.kt:200`.
This change removes the flaky
behavior by sorting the input files.
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)
```
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
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
Ivan Kylchik