- 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
Besides usual pros of kts, it simplifies potential reuse
of code from other build.gradle.kts (namely, Interop:Indexer).
Also, this commit fixes red code in IDE by adding proper dependencies.
#KT-53947 fixed
without the fix, in the presence of the implicit receiver of the same
type as the processed receive, the lowering was incorrectly substituting
the correct receiver with the accessor to the implicit one
Split lib modules, which will be useful for reusable lib modules (if
there are multiple source modules that depend on same lib modules), are
not quite necessary for a project structure built from compiler
configuration. Those rather trigger OOM if lib modules' scopes are not
disjoint.
Mads Ager