During coroutines transformation, we analyse liveness of local variables
in order to decide whether we need to spill them or not.
This analysis contains hot method `useVar`, in which we previously
iterated over all variables in LVT. This is done, since these variables
are seen by debugger and we assume they are alice.
However, this variables can be generated by inliner. In this case, the
LVT's size in huge. I.e. we have loop in hot method.
By hoisting the liveness analysis of the LVT and combining its result
with result of usual liveness analysis, we achieve speed-up from 2m30s
down to 5s.
#KT-30603 Fixed
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
The type mapper does not map enum parameters and outer this parameters
to the right parameter signature kinds so around half the tests
are still failing. Since a new type mapper is being worked
on I will not investigate that further right now.
Two known issues with generateNonPartClassDeclarations that was here
before were the fact that we didn't sort sealed classes and its
subclasses which led to NoSuchMethodError (KT-27097), and the fact that
we didn't skip expect classes which led to incorrect duplicate JVM class
name diagnostic (KT-30843)
#KT-27097 Fixed
#KT-30843 Fixed
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.
Previously,
* Equals performs IEEE 754 equality check for floating points and
byte-to-byte checks for other types, including references.
* Ieee754Equals performs IEEE 754 for primitive types
* TotalOrderEquals performs total order equals to all types, including
floating points.
Now it is simplified,
* Equals performs total order checks for all types.
* Ieee754Equals performs IEEE 754 for primitive types.
* (TotalOrderEquals is removed.)
After cold stream related fixes, we do not generate state machine until
the very last transformation of the lambda. Thus, it is safe to
generate debug metadata for that lambda.
#KT-30694 Fixed
Caused by: java.lang.ClassCastException:
kotlin.collections.EmptySet cannot be cast to java.lang.Void
at org.jetbrains.kotlin.codegen.coroutines.CoroutineTransformerMethodVisitorKt.findSafelyReachableReturns(CoroutineTransformerMethodVisitor.kt:984)
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>