`hasEqualFqName` is called from `hasAnnotation`, which takes more than
1% of total backend time, so it's important to avoid doing extra work
here.
It seems to be a quirk of the JS IR backend specifically that
`JsExport.Ignore` has incorrect IR parent structure here; for all other
backends, checking FQ name by traversing IR parents should work fine.
#KT-66281
`AbstractTypeChecker.isCommonDenotableType` calls a few functions which
check if the type is flexible, which is not cheap in case of JVM IR, see
`asFlexibleType`.
#KT-66281
```kotlin
// FILE: AB.kt
interface A {
val x: Int = 1
}
interface B : A {
// f/o val x: Int
// overrides: A.x
}
// FILE: C.java
public interface C extends B {
// f/o val x: Int
// overrides: (B, A.x)
}
// FILE: D.java
public interface D extends C {
// f/o val x: Int
// overrides: (C, A.x)
}
// FILE: usage.kt
fun test(d: D) {
d.x
}
```
In such test backend will ask for overriddens of lazy property C.x only
after property lowering, which removes property `B.x` and replaces it
with getter `B.<get-x>`. That fact that there is no property anymore
really confuses `SpecialFakeOverrideSymbolsResolver` during computation
of overriddens of `C.x`.
So, to prevent this situation, we can process all source kotlin classes
beforehand, so when any lazy function/property will start computation
of its overriddens, there won't be the need to calculate mapping of
f/o for classes
This problem was found during work on KT-66341, after total signature
computation removal from fir2ir. Previously those fake-overrides just
matched by signature in symbol table
Those only implement base classes, their members are not supposed
to be referenced directly (those sometimes they are).
So unused code in there can be suspicious.
On the other hand, some generated builders are truly unused, so leave
the suppression for them.
There were several problems with it:
1) `isMoreSpecific` should return true if a == b. Otherwise
`isMoreSpecificThenAllOf` would never return true because it's always
invoked with a collection that contains the candidate. K1 behaves
similarly, `OverridingUtil.isMoreSpecific` returns true if a == b.
So in fact, "more" should be understood as "not less" here.
2) `transitivelyMostSpecificMember` in `selectMostSpecificMember` was
always equal to the first element, so `isMoreSpecific` was invoked
with incorrect arguments.
3) At the end of `selectMostSpecificMember`, we selected the first
candidate with the non-flexible return type, however only dynamic
type was considered. We need to check `isFlexible` via type system
instead.
#KT-66120 Fixed
in effort to simplify implementation classes when possible.
Those two properties always point to IrFactoryImpl, so it may as well
be used directly.
#KT-65773 In Progress
It was the only IrElement with custom toString. And there is
a pending MR, which will override toString in IrElementBase, so this one
would be useless.
#KT-65773 In Progress
Invert the logic of IR/FIR2IR-based generators: change the CLI argument
to -Xuse-fir-fake-override-builder, test directive to
USE_FIR_BASED_FAKE_OVERRIDE_GENERATOR, etc.
The changes in test data caused by using IR fake override builder by
default are in the subsequent commit.
#KT-61514
This change fixes FIR tests with JVM IR serialization enabled, some of
which start to fail after enabling IR fake override builder mode by
default.
In this case, even accessing the function body with `IrFunction.body`
does not work in some cases because it tries to load IR and ends up with
unbound symbols for some reason (most likely related to KT-63509). So we
avoid accessing the body by copying the `IrFunction.acceptChildren`
implementation and removing the `body.accept` call.
Using deep-copy to create a fake override is questionable here, but it
will need to be refactored separately.
IR expressions are left out for now, because unlike declarations,
which are mostly created via IrFactory, expressions' constructors are
widely used, and it's hard to replicate the exact signatures of those
constructors with the tree generator.
Therefore, some other approach is expected to be taken when generating
them in the future.
^KT-65773 In Progress
Wojciech Litewka