System property `compilerClasspath` in tests references absent file
cannot find (.../kotlin/prepare/compiler/build/libs/kotlin-compiler-1.6.255-SNAPSHOT.jar)
java.io.FileNotFoundException: cannot find (.../kotlin/prepare/compiler/build/libs/kotlin-compiler-1.6.255-SNAPSHOT.jar)
at org.jetbrains.kotlin.compiler.client.CompilerClientIT.filesFromProp(CompilerClientIT.kt:63)
at org.jetbrains.kotlin.compiler.client.CompilerClientIT.access$filesFromProp(CompilerClientIT.kt:40)
at org.jetbrains.kotlin.compiler.client.CompilerClientIT$compilerClasspath$2.invoke(CompilerClientIT.kt:47)
at org.jetbrains.kotlin.compiler.client.CompilerClientIT$compilerClasspath$2.invoke(CompilerClientIT.kt:46)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
...
Previously enhanced symbols were cached inside SignatureEnhancement,
which is created independently for each enhancement scope. This may
cause creation of multiple enhanced symbols for same java declaration
in presence of multiple scope sessions (mutithread compiler, IDE,
separate scope session for checkers)
^KT-50858 Fixed
This big refactoring is needed to cleanup building of overrides
mappings and prevent creating redundant intersection overrides in
cases when there is no need in them:
```kotlin
interface A {
fun foo()
}
interface B {
fun foo()
}
interface C : A, B {
override fun foo()
}
```
Before this refactoring there was next override tree:
C.foo
intersection override (A.foo, B.foo)
A.foo
B.foo
Also this commit fixes special mapping of overrides in jvm scopes
for declarations which have kotlin builtins in supertypes with
special java mapping rules (collections, for example)
This is much more correct, because we have one to one mapping for
special java functions in this case, so using single nullable name
instead of list of names makes code more readable
It's safe as not having const is more restrictive, therefore can be
allowed in common. Otherwise, it's not possible to declare an expect
declaration for a platform property with `const` modifier in common
KT-18856
If something called from an ObjCExport bridge throws a Kotlin exception,
treat it as fatal by default and terminate the process.
This affects
* Runtime calls (managing and converting Kotlin and Obj-C references and
other types), that shouldn't throw such exceptions anyway
* User code (Kotlin function object throws Kotlin exception when
called from Swift/Obj-C).
If an exception should be handled non-fatally (e.g. forwarded to
the caller), this intention should be expressed in the code generator
explicitly.
^KT-50830
This change makes the code more simple and efficient,
and the control flow -- more explicit.
If a Kotlin exceptions is thrown out of a native code in ObjCExport
(when calling Swift/Obj-C method overriding Kotlin method, or calling
Swift/Obj-C block as Kotlin function type), treat this exception as
fatal and terminate the process.
This could happen if the Kotlin exception leaked from Kotlin to native
code before.
In other words, when calling Kotlin -> Swift/Obj-C -> Kotlin, if Kotlin
exception passes from the last to the first part, terminate.
^KT-50830
Otherwise the tests are flaky for some reason; stack overflow is thrown
from psi2ir sometimes. Probably it has something to do with the fact
that the JVM stack which is used by the compiler here is around the
default limit (which is 1M).
Igor Yakovlev