The lowering that inserts explicit returns into returnable blocks uses
the character offset of the returnable block for the newly created
return statement. This is wrong, but only noticeable when the callee is
an inlined function in another file, where the statements of the block
belong to callee rather than the caller.
The fix takes the offset of the last statement in the block. In the
case the block does not contain any statements, it falls back to using
the offset of the block itself.
The test does not impose any specific stepping order, since this would
be too fragile. It only tests that LLDB does not step to empty (or fully
//-commented) lines.
Co-authored-by: Troels Lund <troels@google.com>
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
}
It's necessary because during substitution it might be necessary to combine
attributes from the original type (this) and substitution
where OriginalProjectionTypeAttribute is actually expected to be null.
Probably, it's worth considering some kind of assertion
that `other` is always null or their projections are the same.
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
Victor Petukhov