Specifically, this commit improves the stepping behavior of the IR
backend around functions with defaults.
- Improved line numbers in the default handler itself for better
stepping when inlined.
- Improved source information on default arguments
- Improved test coverage of stepping behavior in old and IR backends.
Improves the stepping behaviour around inline methods with default
arguments. In particular, we now accurately step through the
evaluation of default arguments, but do _not_ spuriously show the exit
from the $default handler.
If `mapLineNumber` was called in non-monotonic order, e.g. N then N+2
then N+1, the first two calls created a range that spans [N; N+2] but
the third call did not reuse it.
The fields containing crossinline lambdas should be package-private to
avoid generating synthetic accessors, which break object regeneration.
Note that the inline methods cannot actually be called, as call sites
will attempt to read the captured lambda from a field through a *copy*
of the local containing the object, so these reads will not be inlined,
causing an exception at runtime:
inline fun f(crossinline g: () -> Unit) = object : I {
inline fun h() = g()
// effectively `val tmp = this; return tmp.$g()`:
override fun run() = h()
}
f {}.run() // NoSuchFieldError: $g
This particular example can be fixed by reusing locals for receiver
parameters in IrInlineCodegen, but explicitly assigning `this` to
another variable and calling an inline method on it will break it again.
(This is only applicable to the JVM_IR backend, as the non-IR one fails
to generate `f` at all for some other reason.)
Otherwise, the assumption that coroutine codegen makes about every
inlined function already having the markers breaks and it is no longer
true that calls to inline lambdas do not require them.
This is one example of a function replaced by a lowering after
AddContinuationLowering mentioned in the last commit: the lowering that
makes default stubs static is further down. Although this is not a
lambda, calling getOrCreateSuspendFunctionViewIfNeeded on it in the
inliner is fatal all the same.
Private $$forInline versions of public suspend functions should not
be mangled. (Note that there are no $$forInline versions of private
suspend functions, as those are effectively inline-only.)
* unify various checks for whether a suspend function needs a
continuation;
* mark the continuation parameter with an origin (this also allows
correctly computing the offset of the local in codegen -- see the
new test);
* when wrapping `suspend fun main`, use a suspend reference instead of
a synthetic non-suspend lambda (required to correctly implement the
previous point, as previously the continuation parameter was passed
to main() itself correctly only because of very lenient checks in
AddContinuationLowering).
* 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?..)
We always set the $assertionsDisabled field based on the top-level
enclosing class. This means that for anonymous objects we have to
rewrite the call to Class.desiredAssertionStatus.
parameters of inline function. Otherwise, it leads to AnalyzerException,
when inlined lambda contains try-catch block. The reason is simple:
in try block, we leave some variables on stack, while on catch block the
stack is empty. Spilling the variables before try block does the trick.
#KT-34708 Fixed
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 only case where this code is reachable at all is objects in lambdas
that use reified type parameters of the outer inline function. Since the
type parameters are declared outside the inlining root, regenerating the
object is actually pointless, and remapping its captures even more so
(not to mention that the code under the condition uses the captures of
the lambda, not of the method it's currently transforming).
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.
Mikhail Bogdanov