The patch adopts and reuses the optimizations from the legacy backend.
The optimizations remove useless temporary variables,
statements and simplify generated JS code.
The optimizations can be disabled by `-Xoptimize-generated-js=false`.
Related to KT-51139
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
We will need it to generate original names for catch parameters in
sourcemaps.
Also, don't generate redundant debug info for compiler-generated
exception handling control flow operators.
See the doc comment to the MultipleCatchesLowering class
#KT-46276
- Map generated explicit Unit returns to the closing brace of
the original body
- Name the continuation parameter as `$completion` to match the JVM BE,
and generate debug info for it (so that it appears in the 'names'
array in sourcemaps)
- Don't generate debug info for coroutine instantiation ceremony
(so that the user doesn't need to step in many times to get where they
want)
#KT-46276
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
We already have stepping tests for Kotlin/JVM.
They are helpful for testing the correctness of the generated
debugging information.
They are better than line number tests in that they allow to test the
_behavior_, not the generated data. The structure of the data may change
even if the behavior stays the same. For that reason, stepping tests
are more stable.
This also changes the transformation to inline the body of a directly
invoked lambda rather than producing a call to an anonymous local
function. The latter is unsupported in inline functions and problematic
from an ABI perspective, since it results in functions whose name
depends on the entire source code up to this point.
All tests in this commit _pass_ to document existing behavior, but
this will change in a separate commit as we reflect desired behavior
in the test expectations.
E.g. in `x + f()` where `f` is an inline lambda, the instructions for
`+` should have the line number of that expression (while previously
they instead had the line number of the last line of the lambda).
^KT-51738 Fixed
This commit introduces support for calling and referencing local functions and
objects in evaluate expression on the IR backend.
The primary incision is a lowering inserted after Local Declaration Lowering,
that uses the intermediate data structures recorded by LDL to rewrite calls to
local functions to the appropriate function in the binary, instead of predicting
the compilation strategy. The required changes to the rest of the pipeline
facilitate piping the required data around.
The key to this transformation is that _captures by the local function_ must be
introduced as _captures by the fragment function_, such that the evaluator
infrastructure can find the appropriate values at run-time. This is necessary
due to the strategy of compiling local functions to static functions instead of
closures.
Additional test coverage of stepping behavior support the corresponding changes
in the Evaluator, part of the Kotlin Debugger plug-in.
Ivan Kylchik