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.
This allows removing a hack in the MethodSignatureMapper.
When introducing non-getter methods that dispatch to a getter
we have to be careful to use the right name.
DeepCopyIrTreeWithSymbols should create the link between new
properties and their new getter/setter.
In cases when signature of special bridge is the same as current method,
but type is not 'Any?'.
Also there is tiny optimization:
only null check needed if value parameter type is mapped to Object,
but it's not nullable.
#KT-9973 Fixed
0. Such properties are called special because their accessor JVM name differs from usual one
1. When making call to such property, always choose special name
2. When generating Kotlin class inheriting such property generate `final bridge int size() { return this.getSize(); }`
3. If there is no `size` declaration in current class generate `bridge int getSize() { // super-call }`
Dmitriy Novozhilov