If there is superinterface (more specifically, fun interface) in one
file with default suspend function, we lower the function, adding
continuation parameter. Then, when we compile another file with a child,
we generate a bridge to the default suspend function, which is already
lowered. So, we do not need to add the continuation parameter.
If the child is in the same file, then we add continuation parameter
after we create a bridge, so, AddContinuationLowering can encounter
bridges to suspend default functions in superinterfaces with
continuation parameter only in multifile examples.
#KT-47549 Fixed
Compared to FE1.0, instead of using UNRESOLVED_REFERENCE, a new
UNRESOLVED_IMPORT diagnostic is introduced. This is so that we can use a
different positioning strategy to highlight the last part of the import
if the entire import is passed.
Also, this change fixed some incorrectly rejected imports in FIR. Such
cases are covered the newly added test file staticFunAndPropertyImport.kt
* kotlinx.atomicfu compiler plugin for JS_IR
Support transformations of atomic operations introduced by the kotlinx.atomicfu library for the JS_IR backend. Compiler plugin is applied externally by the kotlinx.atomicfu gradle plugin.
* Apply compiler plugin for JS platform only
* New plugin test structure
* testGroupOutputDirPrefix changed
Interfaces (regular and sealed) are by default polymorphic. To benefit
from sealing (i.e. knowledge of all inheritors in compile-time), @Serializable
annotation may be added on sealed interface, generating the same serializer
that can be used for sealed classes.
Synthetic nested classes are not generated in DEFAULT_IMPLS mode because
it causes problems when adding a synthetic companion to an interface.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/1576
This method was used for coercing `Long` values to JavaScript
`number`. However, it caused issues when `Long` values were
concatenated to a string (see KT-8666, KT-26706).
As of Xcode 13.1 Swift 5.5 passes wrong libclang_rt to simulator targets
(similar to ours KT-47333). To workaround this problem, we explicitly
provide the correct one.
Inline functions called by the fragment is detected by the fragment
frontend and the PSI for them is supplied to the compiler backend.
For the purpose of compilation, the inline function is considered as
part of the same source module as the fragment, and then discarded
upon loading the compiled fragment for evaluation.
Sergej Jaskiewicz