Also,
1. remove some redundant copies;
2. fix remapping of non-local returns in lambdas if the body is moved
after LocalDeclarationsLowering (the lambda is no longer inside the
body, but must still be visited)
In case of inline it should be same descriptor (except of fake override), In general case getter could be synthetic accessor and in such case it's not inline
For example, a lambda `{ param -> captured }` of type `E.(T) -> U` will
be transformed by LocalDeclarationsLowering into a private static method
fun f$lambda-0($this: E, $captured: U, param: T) = $captured
The reason for such an ordering is that a lambda looks the same as a
local function, and local function can have default arguments, and those
arguments can reference captured variables; thus, captured variables
must come before actual declared arguments.
However, this is not the order that the inliner wants. Moreover, since
it was written to handle lambdas represented as `invoke` methods of
anonymous objects, it does not expect the actual callable method to have
any parameters corresponding to captured variables at all. This results
in it attempting to generate a temporary node with descriptor
(LE;LU;LT;LU;)LU;
while still using locals 1 and 2 as `param` and `$captured` respectively.
In the example above, this is not critical, as they both have reference
type and the lambda will eventually be pasted into a different node
anyway; however, if it happens that one of them is a primitive, or both
are primitives of different types, the bytecode will use incorrect
instructions, causing verification errors. The correct descriptor is
(LE;LT;LU;)LU;
As for SAM wrappers, the bytecode sequence
new A
dup
new B
dup
invokespecial B.<init>
invokespecial A.<init>
breaks the inliner, so instead we do
new B
dup
invokespecial B.<init>
store x
new A
dup
load x
invokespecial A.<init>
To avoid bytecode sequences like
new _1Kt$sam$i$java_lang_Runnable$0
dup
new _1Kt$f$1
dup
invokespecial _1Kt$f$1.<init>()V
invokespecial _1Kt$sam$i$java_lang_Runnable$0.<init>(...)V
as the different order of `new` and `<init>` confuses the inliner.
NOTE: jvmCrossinlineLambdaDeclarationSite.kt is muted because the
inliner does not remap references to an anonymous object's parent
class after regenerating it. Unlike the JVM backend, JVM_IR uses the
top level named class' assertion status for all inner classes. (The
test used to pass because the lambda in `inline fun call` read the
`$assertionsDisabled` field of `CrossinlineLambdaContainer`, which
was not reloaded after changing the assertion status of package `test`.)
This fixes the problem where compiling a class initializer that contains
a call to an `assert`ing function in a separate module causes the
assertion to always be enabled (i.e. the attached test used to fail in
CompileKotlinAgainstInlineKotlin mode).
and fake lambda types, too. (But those only matter for debugging.)
Also, share object name generators between methods with the same name to
avoid rewriting objects from one with objects from the other.
Any access to a function from a multi-file part needs to be replaced
with the access to the corresponding public method (if it exists) from
the facade class. Note that this has no immediate effect because we use
KotlinTypeMapper for mapping calls, and it understands that a call to a
function from the part must actually be generated into a call to the
function from the facade in the bytecode. This commit merely changes the
IR to better reflect what's generated in the final bytecode, and to be
able to use simplified IR-based method signature mapping instead of the
legacy KotlinTypeMapper in the future.
Previously it was linear scan, failing on unbalanced suspension markers.
Now, I use CFG to find end markers, which are reachable from start
markers. Using CFG allows to walk through suspension point instructions
only, since they form region.
If, for some reason, end marker does not exist (inliner or unreachable
code elimination pass remove unreachable code) or is unreachable,
just ignore the whole suspension point, as before.
#KT-33172 Fixed
#KT-28507 Fixed
It uses isStaticMethod to determine whether to set ACC_STATIC, which is
not correct (see PR #2341). This results in using incorrectly typed
opcodes (as all arguments are shifted by 1) when modifying the inlined
lambda's bytecode. For example, in the test added by this commit, these
opcodes are inserted to spill the stack into locals before calling
another inline function.
Because getMethodAsmFlags is used by the non-IR backend (see PR #2341
again for why changing stuff might not be a good idea), the proposed
solution is to ditch it completely and override generateLambdaBody in
IrExpressionLambdaImpl to use FunctionCodegen's IR-based flag
computation logic.
in OUTERCLASS field.
The inliner generates two versions of suspend functions/lambdas in
inline functions: with state-machine and without. The former is used
to call the function from Java or via reflection and have ordinary
name, while the latter is used by inliner and have $$forInline suffix.
The inliner throws the state-machine version away, duplicates
$$forInline version and then call state-machine generator.
If these suspend functions/lambdas are not going to be inlined,
$$forInline version is not generated. However, all objects, which are
used in these suspend functions/lambdas, have $$forInline version
written to OUTERCLASS field. This leads to errors by proguard.
Since they are used in both state-machine version and for-inline ones,
we can simply remove $$forInline suffix from OUTERCLASS field and this
fixes the issue.
#KT-31242 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
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)
The generated code is more inline with java, and we avoid the error of
accessing package-private field outside of the package.
However, this changes semantics a bit. Now, a user should set assertion
status of inline-site's package, instead of inline function's one.
#KT-28317: Fixed
ASM has logic that splits exception tables in MethodWriter.computeAllFrames:
// Loop over all the basic blocks and visit the stack map frames that must be stored in the
// StackMapTable attribute. Also replace unreachable code with NOP* ATHROW, and remove it from
// exception handler ranges.
...
firstHandler = Handler.removeRange(firstHandler, basicBlock, nextBasicBlock);
...
https://gitlab.ow2.org/asm/asm/issues/317867
#KT-28546 Fixed
Original problem is that lowered ir closures doesn't meet inliner expectations
about captured variable position in inlining method.
E.g.: Call 'foo(valueParam) { capturedParam }' to
inline function 'foo' with declaration
inline fun foo(valueParam: Foo, inlineParamWithCaptured: Bar.() ->) ....
is reorganized through inlining to equivalent call foo(valueParam, capturedParam1, cp2 ...).
But lowered closure for lambda parameter has totally different parameters order:
fun loweredLambda$x(extensionReceiver, captured1, cp2..., valueParam1, vp2...)
So before inlining lowered closure should be transformed to
fun loweredLambda$x(extensionReceiver, valueParam1, vp2..., captured1, cp2..)
#KT-28547 Fixed
Alexander Udalov