Namely:
- Generate debug info for closing braces, which allows the breakpoints
set on closing braces to be hit
- Generate debug info for 'if' and 'try/catch' statements.
KT-46276
Do not generate linenumber for the start of the finally block, because
that is usually where the only word 'finally' is located. Instead,
generate linenumber for the first expression inside the finally block.
Not generating this linenumber fixes an issue in code coverage tools
which would consider such finally uncovered. Although this might be
technically considered as designed, it makes more sense to NOT detect it
as uncovered because semantics of the finally block shouldn't really
differ whether it's executed normally or because an exception happened.
It's also beneficial for the tool support to behave like javac, which
doesn't generate the linenumber either.
#KT-50973 Fixed
This avoids an extra call to 'analyze', which is rather costly.
Update debugger testData: Constant condition
elimination now performs DCE more consistently.
In particular, the current line numbers could lead to stepping
into the catch handler even when the code in the try did not
throw an exception.
This was caused by the code materializing the final value having
the catch line number. This patch delays the materialization
until the line number of the usage has been emitted.
These line number tests only tested that a set of line numbers where
present in the java bytecode. Not that they would be hit in the
right order by the debugger. Moving them to stepping tests fixes that.
This exposes a couple of issues (in particular around try-catch-finally)
that should be fixed.
A number of tests are marked as failing now. Will investigate and
work on fixes next.
Sergej Jaskiewicz