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
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 change is to fill the gap between Kotlin Collection
classes(immutable) and Java Collection classes(mutable), to avoid
calling an unsupported operation like remove() on an immutable class in
jvm.
Platform is trying to modify the class inheritance list during intension (see the test name above) action process but it cause a cross-language changes via PSI.
To make this possible LightClasses are supports this behaviour with a little support of it (inheritance list Add and inheritance list element Delete are supported).
It need's to be done for UL-classes in same way.
IrConstructorCall gets type parameters from the class in addition to the
constructor declaration. This behavior is already implemented for
ClassConstructorDescriptorImpl, but was not implemented for
WrappedClassConstructorDescriptor, leading to missing type arguments for calls
to constructors generated in a lowering pass.
This was already disabled on buildserver with a35f368ce0, but makes
sense locally too because otherwise IntelliJ renders a lot of output
which takes lots of memory and slows down the test runner
The comment in the code is correct that EnclosingMethod
attributes should only be generated for local and
anonymous classes. We were generating them for member
classes as well which leads to invalid class files.
With this change I had to mute one more tests. That is
because we lose the parent method and therefore we
see a class as a member class instead of a local class.
With the old descriptor based check that test still
passes.
Remove "JVM_TARGET: 1.6" directive from box tests and remove tests with
JVM target 1.8. By default, box tests are run with JVM target 1.6, and
there's an additional configuration `codegenTarget8Jvm8Test` that runs
all box tests with JVM target 1.8.
Also, remove box tests with JVM target 1.6. They aren't needed because
even if we manage to generate incorrect bytecode with target 1.6, the
corresponding box tests will catch that
Create TestFile instances for .java sources similarly to .kt sources,
and write them to a temporary directory via writeJavaFiles in each test
where this is needed
Alexander Udalov