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.
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.
Note: neither the new nor the old data is actually correct, as the
debugger needs to stop on line 7 twice (once for the call, once for the
lambda) but ignore the synthetic line number in between.
for DebugMetadata and CoroutinePanel, some corner cases fixed, test
cases added.
Added:
- external maven dependencies in test scenarios
- comparing stack traces + variables on breakpoint
KClass can be 'unboxed' to a plain Java class. Debugger should be aware of this.
Unfortunately, this commit is not enough to fully support this scenario, as it's impossible to invoke KClass methods/extension on java.lang.Class instance. There should be an additional diagnostic that will forbid such calls.
This commit fixes the following tests:
- KotlinSteppingTestGenerated.Custom.testStepOutInlineFunctionStdlib
- KotlinSteppingTestGenerated.StepOut.testStepOutSeveralInlineArgumentDeepest
The main goal is to make behavior similar to what happens in Java. For instance, now we always skip lambdas.
Also, we can reliably use '$i$f' and '$i$a' synthetic local variables. There is no need in complicated hacks any more.
Alexander Udalov