```kotlin
// MODULE: a
interface Base {
fun foo()
}
expect interface Derived : Base {
// f/o fun foo() // (1)
}
// MODULE: b()()(a)
actual interface Derived : Base {
// f/o fun foo() // (2)
}
```
Before this change `FakeOverrideIdentifier` for (1) and (2) were the same,
which led to the problem when referencing (2) in `b` module returned symbol (1)
This behavior affected two places:
1. Referencing function symbol in some call. Here it wasn't an issue,
because IrActualizer changed reference to (2) anyway
2. Creation of IR declaration for (2) in `FakeOverrideGenerator.createFakeOverriddenIfNeeded`.
Previously it worked because of the following hack at `FakeOverrideGenerator:283-286`
```
takeIf { it.ownerIfBound()?.parent == irClass }
```
Generator referenced symbol (1), checked the parent and refused it, because
its parent was different from `actual interface Derived`. Then it called
declaration storage to create new IR declaration for (2), which unconditionally
created new symbol for (2). But after previous commit logic of creation
new declarations was changed: declaration storage extract potentially
unbound symbol from cache and then creates a new declaration with this symbol.
But cache still contains symbol (1) for given FakeOverrideIdentifier,
which leads to the problem that we try to create new IR declaration
for already bound symbol
To fix it and be able to distinguish f/o ids for (1) and (2) additional
flag is added to FakeOverrideIdentifier, which shows if containing class
of corresponding f/o is expect or not
Try to use `IrModuleFragment` instead of `ModuleDescriptor`. This change
is required for the evaluate expression in IDE. When we compile
some code fragment with inline function call that has an anonymous
object in callee, we will get incorrect behavior. Code fragment is
wrapped in `EvaluatorModuleDescriptor` and we accidentally
think that inline call and callee are in different modules that
leads to an error in `AnonymousObjectTransformer.doTransform`.
#KT-63454 Fixed
because WARNING versions of them were already released at some point.
The following declarations were not promoted and have to be promoted later:
- KmProperty.hasGetter, .hasSetter
- Deprecations from readStrict/readLenient/write() rework
#KT-63157 In progress
..to the TargetPlatform during the import process.
#KTIJ-27718 Fixed
Merge-request: KT-MR-13072
Merged-by: Aleksei Cherepanov <aleksei.cherepanov@jetbrains.com>
Dmitriy Novozhilov