The current backend does that for some bridges. We do it consistently
for all bridges.
The line number used differs. For the JVM_IR backend, we use the
line number of the class to which the bridge is added. For the
JVM backend, that does not appear to be the case for bridges
in lambdas. I prefer the line number for a lambda invoke bridge
to be the line for the lambda instead os some surrounding class.
Reimplement the same hacky approach used in the old backend (see
cc2fe6b0c6).
Previously, the debugger incorrectly stepped into Collections.kt on
"step over" inline function calls from stdlib like 'any'.
Since `if` and `when` expressions are represented the same way in IR,
the behavior is fixed for both of them. It's not the case in the old JVM
backend, where stepping over `when` conditions still suffers from the
same problem, which the newly added test checks.
Before this change, a test with incorrect .ir.out could pass if the test
execution result was equivalent to the main .out file, which was a bit
confusing.
Loads of temporary variables that contain constants are replaced
with a copy of the constant. This avoids locals loads and stores.
However, the copy of the constant needs to have the offset of
the load and not of the original constant.
Fixes KT-41963.
This fixes smart step into for delegated member functions.
Additionally, we align on the string "memberFunctionName(...)"
for expression non-null checks for both JVM_IR and JVM
backends.
Bytecode generated by JVM IR ensures that on multiline expressions,
every call is stepped over, which seems better than in the old backend.
Also remove kt34905.kt since it duplicates this test case.
The only difference seems to be that step into IImpl.fooOverride is
actually supported in JVM_IR. Also fix slightly incorrect line numbers
in the comments.
The difference is that JVM_IR generates line numbers for the
constructor field initialization.
In this case:
```
29: class B {
30: // comment
31: val bPropVal: Int,
32: // comment
33: var bProbVar: Int
34: ) {
```
the line numbers for the field initializations are 31 and 33 where
in the current backend the whole constructor has line number 29.
JVM_IR has consistent stepping behavior for secondary constructors
and init blocks. This change fixes the expectations for tests that
expect the less consistent JVM backend behavior.
Temporary variable loads in when expressions had the offsets
of the variable declaration. That leads to hacks during codegen
for line number generation.
Instead of those hacks, give the variable loads the offsets of
the context in which they occur. That avoids the codegen hacks
and fixes stepping behavior for more when expressions.
Adds a synthetic line number just before the original function call.
The new line number is recognized by the debugger which replaces the
'step over' action with 'step into' and stops.
Ilya Kirillov