```kotlin
interface A {
fun foo() // (1)
}
interface B : A {
// f/o fun foo() // (2)
}
```
In previous commits it was forgotten to create new FIR declarations for
IR fake-overrides, which led to the situation when `IR lazy functions
of `(1)` and `(2)` both contained fir of function (1) as their base
declaration
It seems this change fixed some cases from KT-42020
For declarations generated by plugins, fir2ir creates special synthetic
FIR files, which are not registered in the regular FirProvider. This
leads to incorrect determination of ir parent for generated declarations,
because `irParent` utility relies on file returned from fir provider
To fix this issue, the new FirProvider for fir2ir is introduced, which
wraps the original provider and allows to register newly created files
Note that this means that it's illegal anymore to use FirProvider from
session anywhere in fir2ir. `firProvider` from `Fir2IrComponents`
should be used instead
Updated tests contain errors which are incompatible with fir2ir conversion
(like `PACKAGE_OR_CLASSIFIER_REDECLARATION` and `EXPECT_AND_ACTUAL_IN_THE_SAME_MODULE`),
so running fir2ir on such code may lead to exceptions
`allowNonCachedDeclarations` mode allows referring source declaration which
does not belong to the set of sources passed to fir2ir (e.g. for debugger
support). So if code refers to such declaration, fir2ir creates symbol
for it but not the IR declaration itself
```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
Vyacheslav Gerasimov