Even if a function is known to be tail call because it's a compiler
generated bridge, the tail return might still need to be added in case
of Unit return type.
They are inline-only.
Generate $$forInline versions of inline suspend functions as private.
This way, there is no nullability annotation on there parameters and return
values. Unfortunately, old BE does generate them.
#KT-37088 Fixed
Otherwise:
* should the dispatch receiver of a call be another call to a `suspend
fun` wrapped in something that is optimized away later, the owner of
the method will be incorrect;
* references to functions returning non-Unit but casted to `() ->
Unit` (allowed by new inference) might in fact not return Unit after
tail call optimization.
* TailCallOptimizationLowering should go into local classes in order to
transform their suspend methods;
* the check for invokes of noinline lambda arguments in codegen was
incorrect, as it also returned true for calls of lambdas stored in
local variables;
* IrInlineCodegen should mark non-inlinable arguments used as inline
suspend parameters;
* detection of suspend/inline call sites was incorrect (or maybe it's
the `compilationContextDescriptor` that was incorrect?..)
`invoke` in suspend lambdas overrides FunctionN.invoke, so the
refactored BridgeLowering already generates correct bridges there.
All the hack does is break overrides of interface suspend methods.
2 tests muted due to duplicate variables found by the validator
If memory serves:
- there is a `suspend inline fun` and a callable reference to it
- the suspend function doesn't remove the original function in this
case anymore
- the duplicate `var`'s are inside the function body and the
callable reference state machine body
Otherwise, on creating suspend function views these functions will clash
with interface ones. Instead, compute name of their continuation classes
based on attributes of the interface class.
Now AddContinuationLowering is responsible for both adding continuation
classes to suspend functions and adding continuation parameters to
them.
Because we cannot create a view if inline suspend function is defined
in another file, we generate a stub without body when we encounter call
to it. And then, when we lower the file containing the function we add
the body. This way we have no unlowered views after the lowering.
Thus, after the lowering there should be no suspend function, which
are not views, therefore, remove VIEW origins.
Because transformations of suspend functions can copy them into another
object, use attribute as a key inside function to view map.
The issue was, that built IR function does not have a PSI element,
which is required to report error on suspend functions inside monitors.
In this case, use PSI element of the class, containing the function,
which is consistent with old BE.
It is easier to introduce a new lowering so the codegen will emit code for the old
tail-call optimizer to understand. Also, this is more flexible and would allow to
optimize cases, which are now feasible with the old optimizer.
Note, that because of bytecode inlining, we cannot replace the old one, but we cannot
emit code, that is simpler for it to optimize.
Since the markers replace ALOAD 0 as continuations, passed to suspend calls, in
JVM_IR we do not need this, since in JVM_IR all inline lambdas are static
functions.
The problem in the added test was that a suspend lambda was represented
by a function reference with a bound argument for the ObjectRef value,
and the corresponding parameter was not the first parameter of the
referenced local function. This happens because
LocalDeclarationsLowering lifts the local function up and adds a
new parameter for the captured ObjectRef (which is bound at the call
site), but the original receiver parameter remains the first unbound
parameter. So, it's no longer correct to rely on the fact that all bound
parameters of a function reference are located in the beginning of the
parameter list, which was kind of assumed in the `withIndex` call in
`AddContinuationLowering.addCreate`.
pyos