Since they are not spilled, the logic for splitting LVT records, that
is applied for spilled variables, was not applied for known nulls.
Fix that by applying the logic to them.
#KT-47749
There used to be code that extended a previous range instead.
However, that does not work as that extension could have the
local cover code where it does not exists. Since we no longer
extend the range of locals, we should always introduce a new
one even if there was another one for a previous range.
CoroutineTransformermethodVisitor attempts to extend the ranges
of local variables in various situations. Probably in an attempt
to give a better debugging experience. However, all of these
range extensions lead to invalid local variable tables where
something is in the local variable table where nothing is in the
corresponding slot.
The code that extends variables to the next suspension point
instead of ending them when they are no longer live has issues
with loops. When resuming and reentering the loop, the locals
table will mention a local that we did not spill and which
is therefore not restored when resuming.
The code that extends local variable table entries if there
are no suspension points between two entries doesn't work
for code such as:
```
var s: String
if (suspendHere() == "OK") {
s = "OK"
} else {
s = "FAIL"
}
```
If the local variable ranges are collapsed into one, one of
the branches will have the local defined in the local variable
table before the slot is initialized.
The coroutine transformation would leave locals in the local
variable table across the code that reloads local variables from
the continuation on reentry. However, when reentering the function
the local has no value until after the reloads from the
continuation.
This change splits the locals in the local variable table to
avoid such uninitialized locals. A local alive across a
suspension point has its range split in two. One that goes
from the original start to the state label for the restart
after the suspension. The other goes from after the local
has been reloaded from the continuation until the previous
end of the local.
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.
it during spill-unspill.
Coerce int to boolean, otherwise, VerifyError is thrown on android
Completely rewrite SpilledVariableFieldTypesAnalysis... again,
but this time use BasicInterpreter
This way, the analysis both does not use SourceInterpreter and
is in line with the rest on analyses.
Otherwise, the generated bytecode is unnecessarily suboptimal in some
(arguably weird) cases.
In the JVM backend, this was an accidental regression in #3260, as I had
not noticed that effectively inline-only functions were handled by a
separate branch in FunctionCodegen. In JVM_IR, I'm pretty sure the
redundant markers have always been there as `isSuspensionPoint` in
ExpressionCodegen never checked for effectively-inline-only-ness.
If an inline class is mapped to a reference type (or an array), it's Ok
to treat JVM view on a suspend function as returning a value of
corresponding inline class (although in reality it returns 'Any?'
because of COROUTINE_SUSPENDED).
See KT-36812. Aside from the problem stated there, D8 will throw out the
entire LVT if it sees a variable that has not been written to (and will
generate incorrect SSA if the slot is reused with a different type).
Note: this only fixes a FIR test because it's missing an `else -> throw`
branch, and default initialization satisfies the verifier and masks the
incorrect control flow.