KT-50120 Partially solved for functions.
ClassConstructors seem to be deserialized with 'isExpect=false'
which will still lead to wrong 'expect/actual matching'
We do it because sometimes we want to treat a regular class as
an inline class. For example, in the Wasm backend we treat classes
with the `@WasmAutoboxed` annotation as inline classes. Also, in
the JS IR backend the `Char` class is declared as a regular class for
compatibility reasons, but we want it to be an inline class for
performance.
[JS] Node downloading for js ir integration kotlin test
[JS] Fix API of Promise
[JS IR] Promise symbol as lazy2
[JS] Support legacy compiler aftertest with promises
[JS IR] Generate finally for promised tests
[JS] Setup it tests for JS IR kotlin-test
Merge-request: KT-MR-5168
^KT-49738 fixed
If we implement default function with default parameters in inline
class, the receivers will be added to parameter list
(see ac7538a269). But since they
are not present in source parameters, we should not count them when we
compute mask for default parameters.
#KT-49977 Fixed
Before that commit, function in coroutine implementation class was
override for both SuspendFunctionN's and FunctionN+1's invoke,
which somehow works, but breaks exporting classes with such functions.
Now it's two separate functions, as it should be normally.
^KT-49395
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
It's not that simple because we still need inline functions bodies
and classes fields which aren't present in Lazy IR. To overcome this,
save additional binary info for a cached library and then use it when needed
tailrec f(x: () -> T = { y }, y: T = ...) = f()
-- at the call we know that in `x` the observed value of `y` is `null`,
but the constructor should still have a single parameter.
This is needed so that SharedVariablesLowering doesn't get confused, and
SharedVariablesLowering should run after TailrecLowering to properly
optimize tailrec calls in inline lambdas.
sebastian.sellmair