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
- Reduce usage of 'isUnderStandardKotlinPackages' check in commonizer source code
- Rely on common module dependencies supplied via commonizer Parameters which not only
Kotlin standard library but may also include common fragments of other libraries
Jinseong Jeon