Extension receivers are currently implicitly noinline, and changing that
would require modifying the syntax to allow marking them noinline or
crossinline.
^KT-5837 Open
^KT-25787 Fixed
^KT-47965 Fixed
^KT-50107 Fixed
^KT-52403 Fixed
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
We need to supply signatures for private declarations even when their
containing file is not known. In situations where the FirDeclaration in
question is already known (i.e. where we are never going to serach for
the declaation based on that signature), FirDeclaration itself is
sufficient as a key.
The tests fail currently because Klibs are generated by the JS backend,
and signatures differ between JVM and JS (on JVM, return types are
included in mangles for simple functions).
This leads to linkage errors.
Once signatures are reworked and harmonized between backends, the tests
will repair themselves.
This is godugly code, where a flag for file level signatures is passsed
around.
An alternative would be not to create file level signatures for toplevel
private clases, since those still need unique names, at least on JVM.
But that would break binary compatibility.
Signatures are due for overhaul anyway. Hopefully this code can be
reverted at that point.
Ivan Kochurkin