This commit addresses 1243c641296e74a572a4f274df72a4cda60635c6 in intellij
In intellij they added registration of "com.intellij.psi.classFileDecompiler" in
`JavaCoreApplicationEnvironment`. And because the `KotlinCoreApplicationEnvironment` inherits
`JavaCoreApplicationEnvironment` we don't need to register this EP ourselves.
This commit fixes in 203 tests + 1.4.30 compiler:
```
java.lang.RuntimeException: Duplicate registration for EP 'com.intellij.psi.classFileDecompiler': first in com.intellij.openapi.extensions.DefaultPluginDescriptor@44f464d1, second in PluginDescriptor(name=org.jetbrains.kotlin, id=org.jetbrains.kotlin, path=/home/builduser/.m2/repository/org/jetbrains/kotlin/kotlin-compiler-for-ide/1.4.30-M1-30/kotlin-compiler-for-ide-1.4.30-M1-30.jar, version=1.2)
at com.intellij.openapi.components.ComponentManager.createError(ComponentManager.java:167)
at com.intellij.openapi.extensions.impl.ExtensionsAreaImpl.registerExtensionPoints(ExtensionsAreaImpl.java:262)
at com.intellij.ide.plugins.PluginManagerCore.registerExtensionPointAndExtensions(PluginManagerCore.java:1334)
...
```
The removed code is probably an outdated code from the age when Kotlin
compiler was using VirtualFiles for operating. Previously the links were
stored and passed further, but now it is only some additional check
(files are unused after the check) with an implicit dependency to
IDEA internals.
The deleted check could probably be responsible for handling references
to JS libraries because of the working compiler daemon.
The code was spotted during an investigation for the
2bf22caeb7 commit (there's a detailed
description in the commit message).
Report warning if old JVM backend is used, and error for JVM IR, which
is supposed to be enabled as default in the next Kotlin release.
#KT-43725 Fixed
Use String.indexOf(..., ignoreCase) instead in all branches to preserve
compatibility with behavior before 1.4.20 that used String.split which
essentially relied on that String.indexOf
#KT-43745 Fixed
This reverts commit 175dd567
The revert fixes the flaky behaviour on Windows in jps-plugin tests.
java.lang.RuntimeException: java.nio.file.FileSystemException:
tempdir_path\jps-build\jslib-example.jar:
The process cannot access the file because it is being used by another process.
Can be reproduced when running KotlinJpsBuildTest after IncrementalJsJpsTestGenerated.
1. IncrementalJsJpsTestGenerated sets KOTLIN_COMPILER_ENVIRONMENT_KEEPALIVE_PROPERTY
2. KOTLIN_COMPILER_ENVIRONMENT_KEEPALIVE_PROPERTY disables environment clean-up.
3. No disposeApplicationEnvironment() call also means no ZipHandler.clearFileAccessorCache()
4. There's jslib-example.jar opening in JsConfig.checkLibFilesAndReportErrors()
5. File handler is not closed and tests fails in tearDown()
Affected tests:
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryCustomOutputDir
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryAndErrors
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibrary
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithLibraryNoCopy
KotlinJpsBuildTest.testKotlinJavaScriptProjectWithTwoModulesAndWithLibrary
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryCustomOutputDir
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryAndErrors
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibrary
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithLibraryNoCopy
KotlinJpsBuildTestIncremental.testKotlinJavaScriptProjectWithTwoModulesAndWithLibrary
including varargs, apparently.
So, we allow unsigned types and unsigned arrays in annotations,
but disallow user-defined inline classes.
#KT-23816 Fixed
If we do, the local variable table will not make sense. As as
example:
```
inline fun foo(getString: () -> String = { "OK" }) {
println(getString())
}
inline fun bar() {
}
fun main() {
bar()
foo()
}
```
leads to the following bytecode:
```
public static final void main();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
Code:
stack=2, locals=4, args_size=0
0: iconst_0
1: istore_0
2: nop
3: nop
4: iconst_0
5: istore_1
6: nop
7: ldc #53 // String OK
9: astore_2
10: iconst_0
11: istore_3
12: getstatic #30 // Field java/lang/System.out:Ljava/io/PrintStream;
15: aload_2
16: invokevirtual #36 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
19: nop
20: return
LineNumberTable:
line 9: 0
line 13: 2
line 10: 3
line 14: 4
line 15: 6
line 16: 7
line 17: 19
line 11: 20
LocalVariableTable:
Start Length Slot Name Signature
2 1 0 $i$f$bar I
6 14 1 $i$f$foo I
4 16 0 getString$iv Lkotlin/jvm/functions/Function0;
```
The `getString$iv` local should not be there. It has been inlined away.
Leaving it in the local variable table leads to inconsistent locals
info. Local 0 contains an int but we declare a local of type
Function0.
- New CirCommonizedClassifiers and CirForwardDeclarations caches
- New CirProvidedClassifiers cache with classifier names loaded from arbitrary modules
- CirClassifiersCache is replaced by CirKnownClassifiers umbrella
- Replace the remaining usages of 'isUnderStandardKotlinPackages' by delegation to
CirKnownClassifiers.commonDependeeLibraries
Jinseong Jeon