'findKotlinClassOrContent()' does not really distinguish between
outer class names and package path components, so it might return
'foo/bar/Baz.Boo' for 'foo/bar/Baz/Boo'. Possibly because
'findKotlinClassOrContent()' potentially returns a raw byte array,
ClassId checking is supposed to be performed in
'extractClassMetadata()'. For Java, it happens inside
'FirJavaFacade.findClass()', yet for Kotlin the check was absent.
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?
Using `ownerLookupTag` might be wrong in case of private constuctors
of inner classes: their owner is an Inner class, but expected
dispach receiver is Outer
Sometimes, it might be called before type parameter bounds are initialized
or even before the symbols are bound to FIR
In such cases, we just assume it makes sense to create DNN there
See the class org.ini4j.Ini used in intelliJ (derived kt class MyIni)
It contains inherited remove override with the following signature:
String remove(Object sectionName, Object optionName)
While also, from kotlin.collections.MutableMap we inherit
boolean remove(Object, Object)
And we should treat them as different methods to have correct signatures
in resulting class scope
class JavaSuperClass {
// members impls with special signature, but it doesn't override any Kotlin specials
}
class KotlinInterface {
// special members
}
class JavaSubClass extends JavaSuperClass implements KotlinInterface {
// we should obtain members from JavaSuperClass with their Kotlinish
// signature, not the Java one
}
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
Mikhail Glukhikh