For non-suspend lambdas annotations are carried over to the
invoke method so that tooling can find the annotation there.
It seems reasonable that annotations are carried over to
the invokeSuspend method on suspend lambdas as well so that
similar tooling can be built and work for suspend lambdas.
When suspend function type is serialized, there is special logic that
adds Continuation parameter, before doing so, type-aliases has to be
expanded, attributes for resulting type should also derive from
expanded type
KT-53193, KT-54062
Add a new DefFile.excludeFilter property that excludes headers
from interop library by given glob.
This change is required to properly support platform libs from Xcode 14
without breaking ABI.
Disable it if we do not have required `noCompiledSerializer` function in
runtime. Leave it enabled in tests.
Rollback some changes for old backend as it is unsupported now.
instead, plugins should emit the code similar to the TYPE_OF one with
a special call to MagicApiIntrinsics.voidMagicApiCall directly afterwards.
This is required because old compiler need to correctly inline code
rewritten by plugin.
Add intrinsic for kotlinx.serialization.serializer<T>() function.
Plugin intrinsic for old backend is removed because it is too hard
and unjustifiable to unify them.
(Old is created first because all intrinsics emit bytecode anyway)
Provide intrinsic for serializer<T>() function so it won't
invoke typeOf() construction and KType->KSerializer conversion
making it fast and truly reflectionless
Add support for recalculating stack size in plugin-defined intrinsics
since it is needed for correct work:
Unify method for recalculating stack size with existing typeOf intrinsic
Add testdata for IR for future intrinsic in IR
- just legacy - report warning about deprecation
- both - report warning about deprecation of legacy
- no compiler explicitly chosen - error about explicit setting compiler
warn from cli legacy compiler
nowarn flag - kotlin.js.compiler.nowarn
KT-42326
KT-53074
Example: if C is a Kotlin class and there is an import of C.Companion.f,
a call to f will need to check if it is a constructor, for which
it will attempt to load C.Companion.f as a Java class. This involves
loading all outer classes, including C itself, as BinaryJavaClass - see
KotlinCliJavaFileManagerImpl - despite the fact that C and C.Companion
have both already been loaded from their Metadata annotations as Kotlin
classes, wasting cycles and polluting caches.
Thus the theoretical motivation for this change is to marginally speed
up FIR.
The real motivation is that with the -Xemit-jvm-type-annotations option,
kotlinc sometimes generates invalid annotations, and reading them with
BinaryJavaClass throws an exception (the Kotlin metadata however is
valid):
// MODULE: lib
// FILE: C.kt
// The constructor has an argument of type
// List<? extends Function1<? super String, Integer>>
// and a ParameterName type annotation with path
// TYPE_ARGUMENT(0), TYPE_ARGUMENT(0)
// which is missing a WILDCARD between the two TYPE_ARGUMENTs
class C(val x: List<(name: String) -> Int>) {
companion object {
fun foo() {}
}
}
// MODULE: main(lib)
// FILE: main.kt
import C.Companion.f
fun bar() = foo() // crashes FIR
The parameter annotation should obviously be fixed too, but invalid
bytecode may already exist in the wild. Also, did I mention that this
change marginally speeds up FIR?
JS IR generates bridges with type checks for special class methods,
however if parent and child type parameters are same,
the JS signature for the generated brige will be clashed with
the JS signature of original method.
This patch changes type parameter name of EnumEntriesList to avoid the clash.
^KT-54011 Fixed
Sergey Bogolepov