The inliner uses module descriptors to figure out if it needs to
regenerate objects.
We should avoid the use of descriptors in the inliner, but this
works as a first quick fix.
The coroutine method transformer extends the range of locals
across code where the local is not live when it is safe to do
so. However, it only bailed out for one case of control-flow
merging, namely backwards branches for loops. That is not
sufficient as there can be control flow merges without loops
where the local is only defined on one control-flow path.
This change generalizes the bailout to any control-flow merge.
^KT-49834 Fixed
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Instead, document that `KType.annotations` returns an empty list for
types created with `typeOf`. Annotations might be supported in the
future.
#KT-49573 Fixed
#KT-29919
Without this directive the test can't be compiled by Kotlin/Native, because the box() function which is annotated with @ExperimentalContracts is called from the generated test runner source code that itself is not marked by this annotation.
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
This shows up in annotation instantiation tests where we need
to make sure to generate a property on the annotation implementation
class for such properties.
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
Dmitry Petrov