Special getter names (like Collection.size()) can be used only in Java
classes with all-java super-types
Because if there is a kotlin class (not interface) in
the middle, we 'materialize' special getters to properties.
For subclasses of `AbstractMutableList<Int>` which are not inline
classes, the special bridge `remove` had a parameter of type `Int`
(mapped to JVM primitive int) before this fix. The hack in
`MethodSignatureMapper` changed this type to `Int?`, yet the body of the
special bridge still loaded it as non-nullable, which resulted in
incorrect bytecode.
It looks like a part of this hack in `BridgeLowering` was made only for
inline classes which are subclasses of mutable collections. Supposedly
it should be extended to non-inline classes, so that `remove` special
bridge would have consistent IR by the time it reaches codegen.
#KT-46516 Fixed
- Add utilities to add new attribute to ConeAttributes
- Get rid of FlexibleNullability attribute (it can be easily inferred
for any flexible type at any moment)
- Fix determining of EnhancedNullability attribute
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)
This change is to fill the gap between Kotlin Collection
classes(immutable) and Java Collection classes(mutable), to avoid
calling an unsupported operation like remove() on an immutable class in
jvm.
Svyatoslav Kuzmich