Dex ignores subsequent line numbers for same instructions and interprets
instruction after inline as if they were inlined. This makes debugger
behaves as if there's nowhere to stop on line with breakpoint.
This also makes stepping through inline function consistent with
non-inline analog. In both context debugger now stops on '}'.
#KT-18949 Fixed
#KT-17120 Fixed
Before this fix line numbers for function call arguments were not generated,
so if argument was on another line than function call it was
impossible to stop on argument line during debugging.
Now line number for each argument is generated if necessary
(another line than function call line).
#KT-17144 Fixed
Remove redundant NOPs during bytecode optimization.
NOP instruction is required iff one of the following is true:
(a) it is a first bytecode instruction in a try-catch block (JVM BE assumption);
(b) it is a sole bytecode instruction in a source code line (breakpoints on that line will not work).
All other NOP instructions can be removed.
Note that it doesn't really affect the performance for mature JVM implementations.
However, the perceived quality of the generated code is somewhat improved :).
Related: KT-15609
Revert changes for "tolerant to uninitialized values" in OptimizationBasicInterpreter:
this approach doesn't converge for some specific cases where local variable is reused
(e.g., in several inlined functions - see https://youtrack.jetbrains.com/issue/KT-15112).
Instead, treat fake always-false conditional jump in the beginning of the post-condition loop as a "reference point" for stack on loop break / continue.
This requires an extra abstraction layer in FixStackAnalyzer, since we can't perform fine-grain manipulations on Frames
(such as "combine frame C from local variables of frame A and stack of frame B").
NB additional NOPs will be generated for post-condition loops.
Should make a separate bytecode postprocessing pass to get rid of unnecessary NOPs
(several YT issues for perceived quality of the generated bytecode are about such NOPs).
Otherwise linenumber for previous instruction will be used in debugger. That can lead to error stepping
because it might be line that isn't reachable on current iteration.
#KT-13059 Fixed
Comma must present now between enum entries, semicolon between last entry & first member, constructor calls must be without colons / specifiers.
A swarm of tests fixed accordingly.
Package classes in line number tests only contain "1" as the first line number
of a single function, so there's no point in testing it. The test was failing
due to the latest changes in the order of generation of classfiles (first $src,
then facade)
Nikolay Krasko