Unlike previously, this optimisation works on every callee return type.
Tail-calls inside unit functions can be either
INVOKE...
ARETURN
or
INVOKE
POP
GETSTATIC kotlin/Unit.INSTANCE
ARETURN
The first pattern is already covered. The second one is a bit tricky,
since we cannot just assume than the function is tail-call, we also need
to check whether the callee returned COROUTINE_SUSPENDED marker.
Thus, resulting bytecode of function's 'epilogue' look like
DUP
INVOKESTATIC getCOROUTINE_SUSPENDED
IF_ACMPNE LN
ARETURN
LN:
POP
#KT-28938 Fixed
In 1.3.31 I fixed Java interop for inline function with coroutines
(TL;DR: when we need a state machine, generate two methods: one with
normal name, and the other one with $$forInline suffix, for the inliner
to use, just like inline suspend functions), however, I forgot a case
with inline suspend function with inline suspend function parameter.
In this case, the compiler a generated two functions, as needed, but,
neither of them had a state-machine. This change adds the state-machine
for the method with normal name. Note, that suspend inline functions
with crossinline parameter, which are also supported by the change,
did not cause incorrect behaviour, since until now they were generated
as synthetic.
#KT-31354 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
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.
Ilmir Usmanov