1. consider reads of fields from the same file "stable" just like
functions, i.e. assume their nullability information is correct
2. apply if-null fusion repeatedly until the subject is no longer a
nested if-null expression
The difference is how we deal with intermediate fake overrides
E.g., in case
interface A { /* $1 */ fun foo() }
interface B : A {
/* $2 */ fake_override fun foo()
}
interface C : B {
/* $3 */ override fun foo()
}
We've got FIR declarations only for $1 and $3, but we've got
a fake override for $2 in IR.
Previously, override $3 had $1 as its overridden IR symbol, just because
FIR declaration of $3 doesn't know anything about $2.
Now, when generating IR for $2, we save the necessary information
and using it for $3, so it has $2 as overridden.
So, it's consistent with the overridden structure of FE 1.0 and this
structure is necessary prerequisite for proper building of bridges
for special built-ins.
FIR translates:
```
when (x) {
1, 2, 3 -> action
else -> other_action
}
```
to an IR structure with nested ors:
```
if ((x == 1 || x == 2) || (x == 3)) action
else other_action
```
This change allows that to turn into switch instructions in the
JVM backend.
i.e. remove the condition that there must be an LVT entry. Such
temporary `Ref`s can be created, for example, by the JVM_IR backend
if a lambda inlined at an IR level (e.g. argument to `assert`/`Array`)
is the target of a non-local return from a function inlined at bytecode
level (e.g. `run`):
IntArray(n) { i ->
intOrNull?.let { return@IntArray it }
someInt
}
->
val `tmp$0` = IntArray(n)
for (i in 0 until `tmp$0`.size) {
var `tmp$1`: Int
do {
intOrNull?.let {
`tmp$1` = it // causes `tmp$1` to become an IntRef
break
}
`tmp$1` = someInt
} while (false)
`tmp$0`[i] = `tmp$1`
}
It's not correct to expect that the backend generates the `when` in this
test as tableswitch because there are only two branches. JVM IR has a
cutoff in the when optimization and generates `when`s with fewer than 3
branches as if-else chains, which is probably better. Note that there's
also a corresponding box test in when/enumOptimization/, so the backend
behavior is still tested.
This gives us more precise type information and can enable backend
optimizations. This was motivated by when expressions not compiled
to table switches in the JVM_IR backend.
Fixed KT-36845.
When synthesizing the hashCode function for data classes, descriptors
were used, in partcular, memberScope for primitive classes.
IrBasedDescriptors have no member scope, so we compute the hashCode
function based on IR structures.
The existing backend restores LVs and parameters from the suspend lambda
fields used for spilling between suspension points, hence they are
visible in the debugger as local variables, plain and simple.
This PR introduces the same pattern to the IR backend, to bring the
debugging experience in line with the existing backend.
Both backends are still at the mercy of the liveness analysis
performed in the coroutine transformer where a liveness analysis
minimizes live ranges of entries in the LVT. E.g. an unused parameter
will be dropped entirely.
Adjusted existing test expectations accounting for the differences in
LV behavior.
The current backend uses direct field access to the backing field
instead of calling the companion object accessor, which calls
an accessibility bridge, which then gets the field for code such as:
```
class A {
companion object {
val s: String = "OK"
}
// f uses direct access to the A.s backing field.
fun f() = s
}
```
This change does the same for the IR backend.
'allopen' compiler plug-in can make data classes and their members open,
which is a compilation error in usual case, but makes sense for Spring
and other frameworks that generate proxy-classes.
pyos