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?
Right now it is the easiest way to ensure that all the parameters are
resolved. After KT-53573 is fixed, we might use `resolvedReturnTypeRef`
on each parameter individually instead
Also, add `toString` implementation to `ValueClassRepresentation`
classes, so they are properly rendered in testdata
^KTIJ-22630 Fixed
Leveraging the same mechanism with $EntriesMapping as Java enums.
Old (compiled with LV/AV < 1.8) enums are detected by looking for
static special <get-entries> method that cannot be introduced on
Kotlin enums otherwise
#KT-53236
This is needed to avoid dependency on :compiler:fir:fir2ir module in
backend parts of compiler plugins. It will allow to publish those
parts into jars for IDE, where they are needed for working of debugger
and bytecode toolwindow
That issue might be fixed via changing
TypeVariableMarker.shouldBeFlexible at ConeConstraintSystemUtilContext
but this and some other tricks have been added because of incorrect
handling of constraints where type variable has a flexible bound
^KT-51168 Fixed
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
pyos