evaluator fragments
- Refactor JvmIrCodegenFactory to allow for caller's choice of
lowerings.
- Refactor of SyntheticAccessorLowering to expose the accessibility
check used to determine the need for accessors.
- Replacement of field, method and constructor uses with corresponding
java.lang.reflection API via additional lowering running _before_
the existing IR pipeline.
- Emulating super calls in the context of class methods via new
compiler intrinsic.
- psi2ir: Add support for `_field` suffix on properties in the
evaluator for accessing underlying fields when applicable.
- Add `JvmGeneratorExtensions` point for determining whether a
property accessor has a user-supplied body in order to predict how
they are ultimately compiled for the JVM.
Incorrect builder was used at line 269, which led to non-sensible type
in `IrClass.thisReceiver` for function types, such as
`SuspendFunction1<SuspendFunction1, SuspendFunction1>` in the linked
issue.
Avoid creating types manually completely to simplify this code and fix
the bug.
#KT-49168 Fixed
1. Move jsInteropFunctionsLowering after callable reference lowering,
so it can continue to deal with just functions and function calls.
2. Generate lowered closure class in JsInteropFunctionsLowering because
In general, we would rather prefer a range-based for loop to look like
a counter loop in Java ('for (i = start; i < end; ++i) { <BODY> }').
This corresponds to
i = start;
do {
if (i >= end) break;
<BODY>
} while ( { ++i; true } )
However, HotSpot doesn't recognize Kotlin unsigned integer comparison
in 'if (i >= end) break;' as a counter loop condition. Thus, the loop
doesn't get optimized as a counter loop, resulting in a performance
regression.
If we use exclusive range-based for loop instead, then we actually use
unsigned integer equality instead of unsigned integer comparison, which
is Ok for HotSpot.
KT-49444
[JS IR] Fix test data after master rebase
[JS IR] Use stdlib's listOfNotNull
[JS IR] Possibility to use export for nested inside object
- Add tests for such cases
Merge-request: KT-MR-4883
^KT-49363 fixed
Putting them in the local variable table means that the debugger
needs to have special handling for parameters with specific names.
That forces us to generate mangled names for these.
Instead of also implementing the name mangling for FIR, this
change gets rid of the parameters from the LVT instead.
Kristoffer Andersen