If an intersection override overrides members A.x, B.x and C.x and
B <: A, then A.x is subsumed by B.x, and we don't add it to the list of
overridden members. This fixes a false-positive MANY_IMPL_MEMBER_NOT_
IMPLEMENTED where an implementation is subsumed by an abstract override.
^KT-57092 Fixed
This big refactoring is needed to cleanup building of overrides
mappings and prevent creating redundant intersection overrides in
cases when there is no need in them:
```kotlin
interface A {
fun foo()
}
interface B {
fun foo()
}
interface C : A, B {
override fun foo()
}
```
Before this refactoring there was next override tree:
C.foo
intersection override (A.foo, B.foo)
A.foo
B.foo
Also this commit fixes special mapping of overrides in jvm scopes
for declarations which have kotlin builtins in supertypes with
special java mapping rules (collections, for example)
In this commit we drop less concrete members in intersection.
See for example change in test data: before the commit, we intersected
all three A.foo, B.foo and C.foo in diamond hierarchy. After the commit
we drop A.foo and intersect B.foo and C.foo only.
If some java class has multiple supertypes then we need to collect
overriddens from all those types directly, even if superTypeScope
(which is FirTypeIntersectionScope in this case) returns only
one symbol from one of this types (not intersection one)
This is needed to proper enhancement in cases when some type occurs
multiple times in supertypes graph with different nullability
of arguments:
class ConcurrentHashMap<K, V> : AbstractMap<K!, V!>, MutableMap<K, V>
If we try to find method `get(key: K): V` supertype scope returns
`AbstractMap.get(key: K!): V!` (because it actually overrides
`MutableMap(key: K): V?`), but we need to get both symbols to
properly enhance types for `ConcurrentHashMap.remove`
Previously we inferred "open" if there was at least one open member in the
hierarchy. However, that's not correct when that member is overridden by
another member in the hierarchy which is abstract. This led to incorrect code
being accepted by the front-end, and an exception during the bridge generation
#KT-12467 Fixed
Kirill Rakhman