Commit Graph

15 Commits

Author SHA1 Message Date
vladislav.grechko f318b5969d Erase non-reified type parameters by-default when inlining.
Substitution of type arguments to non-reified type parameters may lead
to accidental reification, which should not be done (see ^KT-60174 for
examples). So, we should erase them, except the few cases.

^KT-60174: Fixed
^KT-60175: Fixed
2024-01-26 18:31:20 +00:00
Artem Kobzar 327085e026 [K/Wasm] Unmute most of the stepping tests for Wasm in K1 2023-12-28 16:32:10 +00:00
Alexander Udalov 5e330acd28 Tests: remove stepping tests on old JVM backend 2023-12-18 21:42:35 +00:00
Artem Kobzar 05ed134fbb [K/Wasm] Introduce stepping tests for Wasm 2023-08-15 17:03:11 +00:00
vladislav.grechko 17e6099b53 Initialize 'source' property of FirCatch objects properly
^KT-56923: Fixed
^KT-56755: Fixed
2023-03-08 12:03:35 +00:00
Dmitriy Novozhilov 28b83a1a5d [Test] Mute tests due to KT-56755 2023-02-20 08:40:32 +00:00
Sergej Jaskiewicz becbc06663 [JS] Re-enable some stepping tests 2022-11-18 10:37:58 +00:00
Sergej Jaskiewicz c9c50ff73c [JS IR] Disable some flaky stepping tests
^KT-54283
2022-10-04 10:31:14 +00:00
Sergej Jaskiewicz 2ece4f4dbf [JS IR] Improve the precision of execution of stepping tests 2022-08-05 11:53:40 +00:00
Sergej Jaskiewicz 1241565cce [JS IR] Adapt stepping tests for Kotlin/JS 2022-07-19 16:06:24 +00:00
Mads Ager e9c9d5731e [JVM] Port Stepping and LocalVariable tests to new test infra.
This is in preparation for enabling the tests for FIR which will
be easier to do when the tests are on the new infrastructure.
2021-10-15 20:03:54 +03:00
Dmitry Petrov 24fcadb869 JVM don't run CCE on methods without optimizable conditional jumps 2021-07-08 22:11:59 +03:00
Dmitry Petrov 7a43c2de79 JVM remove dead code during constant condition elimination
This avoids an extra call to 'analyze', which is rather costly.

Update debugger testData: Constant condition
elimination now performs DCE more consistently.
2021-06-03 00:08:27 +03:00
Mads Ager f128e5222a [JVM_IR] Fix line number information for try-catch.
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.
2020-06-03 07:33:21 +02:00
Mads Ager 7d7b9262e7 [JVM] Port remaining line number tests to stepping infrastructure.
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.
2020-05-29 15:07:49 +02:00