Before this change, we stored the enclosing constructor in a map in
JvmBackendContext before moving lambdas and local classes out of
initializer blocks. However, in case the lambda was declared in an inner
class, we stored a reference to the unlowered constructor of the inner
class, whose JVM signature is "()V" instead of the correct "(LOuter;)V".
Java reflection then threw exception if we tried to call
`getEnclosingConstructor()` on such class at runtime. Proguard finished
with errors for the same reason.
It turns out that we can just store the fact that the class has been
moved, and load the matching constructor in codegen, where everything is
already lowered and guaranteed to match with the signatures of the
actual generated declarations.
#KT-41668 Fixed
There was a typo in JvmLocalClassPopupLowering which allowed the
EnclosingMethod for lambdas and anonymous classes in initializers to
become any function in a class, in case when there was no primary
constructor in that class. E.g. in the added test, `getIrrelevantField`
was the EnclosingMethod of the lambda class before this change.
In box tests, only check that Java reflection does not crash on the
EnclosingMethod attribute generated in these classes. If it doesn't
crash, most likely it returns the value that can be read from the class
file by ASM, which is what the newly added bytecode listing tests are
checking now.
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
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
Previously, inline suspend functions were effectively inline only,
but ordinary inline functions can be used as noinline.
To fix the issue, I generate two functions: one for inline with suffix
$$forInline and without state machine; and the other one without any
suffix and state machine for direct calls.
This change does not affect effectively inline only suspend functions,
i.e. functions with reified generics, annotated with @InlineOnly
annotation and functions with crossinline parameters.
#KT-20219: Fixed
Alexander Udalov