This change improves the debugging experience around local functions
on the IR backend. The changes include moving old
checkLocalVariablesTable (cLVT) tests to the new stepping/local variable
infrastructure in order to refine the tests and further define the
behavior of the two JVM backends, and their differences.
The primary ported test case is cLVT/localFun.kt that documents the
discrepancy in implementation strategy for local functions on the two
backends. The old backend implements local functions as lambdas
assigned to a local variable while the IR backend lifts them out as
static funtions on the surrounding class. The discrepancies and their
consequences are documented in bytecodeListing, idea-stepping,
localVariableTable and debugStepping tests.
The only _code change_ is disabling the captured variable name
mangling for captured variables on the IR backend. Captured variables
are passed as arguments to the static function, so in the debugger,
they really just are local variables. For them to show properly in the
debugger and be detectable by evaluate expression, they simply need no
mangling.
Finally, this change cleans 3 redundant cLVT tests, copyFunction.kt
and destructuringInlineLambda.kt and destructuringInFor.kt, that are
all covered in the new suite. The stepping behavior needs to be made
precise around for loops, but that is an entirely seperate issue.
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.
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
Before this commit, the substituted FunctionDescriptor didn't have a source element.
As a result, 'CodeFragmentParameterAnalyzer.isCodeFragmentDeclaration' failed to recognize such a descriptor as fragment-local, and it was erroneously captured.
It seems like it doesn't make much sense to create expression code fragments.
People type statements or several expressions separated with a semicolon to a single-line expression line.
That is exactly what block code fragment was designed for.
Kristoffer Andersen