The problem in the test case was that `JImpl.entrySet` was detected by
ReplaceDefaultImplsOverriddenSymbols as a class fake override, which
overrides non-abstract interface method. Thus, overriddenSymbols of
`MyMap.entrySet` were changed in
`ReplaceDefaultImplsOverriddenSymbols.visitSimpleFunction`.
Later, BridgeLowering tried to determine which special bridges to
generate for `MyMap.<get-entries>`, and for that it inspected existing
methods and their overrides.
Normally we would generate the following special bridge:
getEntries()Ljava/util/Set;
invokespecial JImpl.entrySet()Ljava/util/Set;
However, because of incorrect overrides, the generated class method was
selected here instead of the expected `Map.<get-entries>`:
https://github.com/JetBrains/kotlin/blob/06001fc0919c814e757caa494891619882fae15f/compiler/ir/backend.jvm/src/org/jetbrains/kotlin/backend/jvm/lower/BridgeLowering.kt#L282
and since the JVM signature of the generated class method is the same as
that of the fake override in MyMap, we never got to generating the
special bridge.
The solution is to skip Java classes when looking for class methods
which override non-abstract interface methods. This logic only makes
sense for Kotlin code, because only Kotlin has DefaultImpls, and the
requirement to generate non-abstract fake overrides of interface methods
as actual methods in the bytecode, delegating to DefaultImpls.
#KT-48167 Fixed
The difference is how we deal with intermediate fake overrides
E.g., in case
interface A { /* $1 */ fun foo() }
interface B : A {
/* $2 */ fake_override fun foo()
}
interface C : B {
/* $3 */ override fun foo()
}
We've got FIR declarations only for $1 and $3, but we've got
a fake override for $2 in IR.
Previously, override $3 had $1 as its overridden IR symbol, just because
FIR declaration of $3 doesn't know anything about $2.
Now, when generating IR for $2, we save the necessary information
and using it for $3, so it has $2 as overridden.
So, it's consistent with the overridden structure of FE 1.0 and this
structure is necessary prerequisite for proper building of bridges
for special built-ins.
Before this commit we considered !isOverride as a sign that
function / field / accessor has no overridden symbols.
However, it's false for deserialized, because isOverride
is always false there.
This commit fixes 68 BB tests but breaks 25 BB tests (not yet muted)
Without this commit, JVM name mapping logic in BE does not work for FIR,
because FIR cannot use old BuiltInsPackageFragmentImpl descriptor.
In this commit we add our own implementation thus fixing
a pack of FIR black box tests.
Special bridges which are generated as a replacement for a non-final
fake override and use invokespecial to call the already existing
implementation in the superclass, should not be final. Otherwise we
can't generate an override for the original Kotlin function in a
subclass with the same JVM signature.
If there is an existing method that will have its argument types
remapped to boxed types, make sure to reflect that in the IR so
that code will be generated for a boxed value instead of a
primitive value.
In case we extending some Map specialization with non-trivial type arguments,
e.g. Map<String, String> from Kotlin point-of-view it has
"remove(String, String)" signature while in Java it's "remove(Object, Object)".
So, we generate an override "remove(String, String)" in first Kotlin class of the hierarchy,
which body delegates to "super.remove(Object, Object)"
Also, we generate a final override for "remove(Object, Object)" to allow
for Java inheritors choose only the version with String while overriding.
The main idea of the fix is to make mayBeUsedAsSuperImplementation
return true in case of PlatformDependent annotations.
Otherwise, we weren't able to choose the impl from the java.util.Map
as a delegate in our bridge.
Another part of the fix is overriding `isDeclaration`:
it was necessary because otherwise bridge-generation algorithm
was assuming that there's already an actual declaration
in the first sub-class (TestMap) in the test and we need to
delegate to the latter instead of the method from the interface
^KT-26069 Fixed
Mikhail Glukhikh