```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>
In gradle metadata transformations for CInterops in composite builds
it is possible that resolved artifact is not actually created.
For example if host machine is not MacOS but composite build has
projects with enabled Apple targets. So apple-specific tasks will be
disabled but still configured and during dependency resolution
its outputs will be provided in artifact view.
We have already checked for cases when there is no resolved artifact.
But apparently it is not enough, and it is important to check that file
exists physically.
^KT-63197 Verification Pending
Dmitriy Novozhilov