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.
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.
- Use typed Wasm tables for each interface method to avoid runtime
function type check
- Use linear search by implemented interface rather than by individual
virtual function signature
^KT-44055 Fixed
It's possible only if there is a callable reference among subcalls which go though the old type inference (and the error for uninferred type parameter wasn't reported)
It leads to leak such type to the back-end. Calls within a builder call should be updated without marking CR and lambdas with DONT_CARE type.
^KT-43845 Fixed
^KT-43956 Fixed
^KT-42622 Fixed
Svyatoslav Kuzmich