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
}
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
Previously enhanced symbols were cached inside SignatureEnhancement,
which is created independently for each enhancement scope. This may
cause creation of multiple enhanced symbols for same java declaration
in presence of multiple scope sessions (mutithread compiler, IDE,
separate scope session for checkers)
^KT-50858 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)
This is much more correct, because we have one to one mapping for
special java functions in this case, so using single nullable name
instead of list of names makes code more readable
If there is a `coneType` call immediately after the `fir.bounds` call,
it means that the fully resolved type is expected, hence
`resolvedBounds` should be used
so that defaults are available to synthetic implementations.
#KT-48181 Fixed
Implementation is for JVM IR; other backends & FIR need to be supported
separately.
This is needed for two reasons:
1. Before this change companion object appeared in FirRegularClass
twice: in declarations list and in companionObject field. This may
trigger twice transform of it
2. It's very hard to implement generation of companion object by plugins
because if it is part of the tree then generated declaration must be
registered in FirProvider, which is inconsistent with other generated
declarations. Replacing FIR with symbol and removing custom logic of
visiting/transforming companion FIR allows us to just replace companionSymbol
in FirClass if plugin wants to generate it without any additional work
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`
This is needed for debug purposes, because without classId or reference
to class it's very hard to understand which scope you are observing
in debugger
This is needed to avoid problems with checking visibility of types which
are used in supertypes during supertypes resolution in IDE, when
supertypes of some class can be already computed, but not saved in
class itself, but still lay in supertypeComputationSession
There were 4 failing tests before this changes (all in
`DiagnosisCompilerTestFE10TestdataTestGenerated$Tests$Exposed`):
- testInternal
- testInternalAndProtected
- testProtected
- testProtectedSameWay
Ivan Kochurkin