Delegated properties now have their $delegate fields recorded in the
metadata (in `ClassCodegen.generateField`). This part of metadata is
used by `KPropertyN.getDelegate` functions, so almost all tests on
getDelegate are now unmuted
Move kotlin-stdlib-js project and the sources specific to the current backend to 'stdlib/js-v1' directory,
but leave sources that can be shared with the new IR backend in the common 'stdlib/js' location
with exception for 'stdlib/js/src/generated', which is used exclusively for current backend.
This simplifies sourceset configuration when building stdlib with the new backend.
This fixes Java interop of inline functions, which use coroutines.
However, we cannot transform the state-machine. Thus, we generate
a $$forInline counterpart for suspend functions (similar to inline
suspend functions) and invokeSuspend$$forInline for lambdas if these
coroutines are going to transformed (i.e. are declared inside inline
functions).
During transformation we just skip method with state-machine and
transform the $$forInline counterpart. Of course, if inline site is
inline itself, we generate both state-machine version (which will be
dropped during the next transformation) and $$forInline version.
Consequently, the final version of the coroutines will not have
$$forInline counterpart.
Unfortunately, since CompileKotlinAgainstInlineKotlin tests do not allow
java sources, the tests for the interop are usual box tests.
#KT-30707 Fixed
We get the info for the underlying progression and invert it. For
progressions whose last bound was open (e.g., `until` loop), the
reversed version will have an open first bound and so the induction
variable must be incremented first.
Also unified the way of extracting HeaderInfo out of changed calls
(e.g., `indices.reversed()`), and fixed declaration parents in
ForLoopsLowering.
This directive generates TailCallOptimizationChecker in package helpers.
The check for tail call optimization is based on coroutine stack traces
bug (feature?): when tail call optimization hits, the continuation
object is not generated. Thus, there is no debug metadata for this
suspend function. Consequently, the coroutines stack trace does not
contain stack trace element for that function.
This check is performed by TailCallOptimizationChecker.
Since this is runtime check, unlike bytecode tests, it does not require
test data adjustments on each codegen or inliner change.
Since the check is based on debug metadata, which is JVM specific, there
is not support for other backends yet.
if they are not inlined, but directly called.
Previously, all inline and crossinline lambda calls were treated by
codegen as if they are always going to be inlined. However, this is not
always the case.
Note, that we cannot generate these markers during codegen, since we
can inline code with no suspension points, but the whole inlined code
will become one giant suspension point. This, of course, breaks
tail-call optimization and, hence, slows down cold streams.
Because of that, we generate these markers, when we are sure, that they
are not going to be inlined. The only place, in which we know that, is
the inliner. During inlining of the inline function, we check, whether
the parameter is inline or crossinline and whether it is not an inline
lambda. If these checks pass, we generate the markers. Noinline
parameters are already covered by the codegen.
#KT-30706 Fixed
#KT-26925 Fixed
#KT-26418 Fixed
In SourceCompilerForInline we could enter ERASED_INLINE_CLASS context
from containing declaration context. That broke codegen context
hierarchy invariants assumed in accessor generation.
HeaderInfo object, and modifying the operator in the loop condition.
The "additional emptiness condition" is no longer necessary with this.
The open/closed property was removed from HeaderInfo in an earlier
commit, but bringing it back in to simplify the loop building makes
more sense.
Also expanded tests for evaluation order of range bounds.
These tests were added for suspend-conversions, it worked only
with new inference, but implementation was incorrect and had other
bugs, which were fixed in 1ac25259.
Support of suspend-conversions will be addressed later with a different
implementation (#KT-30703)
Effectively, the following when structure:
when (s) {
s1, s2 -> e1,
s3 -> e2,
s4 -> e3,
...
else -> e
}
is implemented as:
when (s.hashCode()) {
h1 -> {
if (s == s1)
e1
else if (s == s2)
e1
else if (s == s3)
e2
else
e
}
h2 -> if (s == s3) e2 else e,
...
else -> e
}
where s1.hashCode() == s2.hashCode() == s3.hashCode() == h1,
s4.hashCode() == h2.
A tableswitch or lookupswitch is used for the hash code lookup.
Change-Id: I087bf623dbb4a41d3cc64399a1b42342a50757a6
Svyatoslav Kuzmich