Old compiler versions still won't be able to load default lambdas
generated by JVM_IR, but this way we avoid incorrect behavior of
function references taking inline class types that unbox to Any.
#KT-46601 Fixed
In the old backend, this was unnecessary because nested objects would
reference their lambdas' captures through the original this$0. On
JVM_IR, using loose capture fields means a name/descriptor clash can
occur on any level of nesting, not just the top.
Note that KT-30696 is fixed only in the single-module case, and KT-42012
is not fixed fully (see KT-44855).
#KT-30041
#KT-30629
#KT-30696
#KT-30933
#KT-32351
#KT-32749
#KT-38849
#KT-42012
#KT-42990
#KT-44234
#KT-44529
#KT-44631
#KT-44647
Not in the frontend or psi2ir, though, so this not a complete
implementation of KT-1436, but rather a part of it that is currently
useful to make other code compile. In particular, lambdas passed to
array constructors and JVM-style `assert` are inlined as IR returnable
blocks, which are then converted into `do { ... } while (false)` loops,
so non-local returns from them become non-local `break`s.
This is a hack to work around the fact that type mappings should not be
inherited by inlining contexts for lambdas called from anonymous
objects. As the lambda can call the inline function again, this could
produce a reference to the original object, which is remapped to a new
type in the parent context. Unfortunately, there are many redundant
`MethodRemapper`s between the lambda and the class file, so simply
editing `TypeRemapper` does not work. Hence, this hack. For now.
(Issue found by compiling IntelliJ IDEA BTW.)
If we do, the local variable table will not make sense. As as
example:
```
inline fun foo(getString: () -> String = { "OK" }) {
println(getString())
}
inline fun bar() {
}
fun main() {
bar()
foo()
}
```
leads to the following bytecode:
```
public static final void main();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
Code:
stack=2, locals=4, args_size=0
0: iconst_0
1: istore_0
2: nop
3: nop
4: iconst_0
5: istore_1
6: nop
7: ldc #53 // String OK
9: astore_2
10: iconst_0
11: istore_3
12: getstatic #30 // Field java/lang/System.out:Ljava/io/PrintStream;
15: aload_2
16: invokevirtual #36 // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
19: nop
20: return
LineNumberTable:
line 9: 0
line 13: 2
line 10: 3
line 14: 4
line 15: 6
line 16: 7
line 17: 19
line 11: 20
LocalVariableTable:
Start Length Slot Name Signature
2 1 0 $i$f$bar I
6 14 1 $i$f$foo I
4 16 0 getString$iv Lkotlin/jvm/functions/Function0;
```
The `getString$iv` local should not be there. It has been inlined away.
Leaving it in the local variable table leads to inconsistent locals
info. Local 0 contains an int but we declare a local of type
Function0.
The main change here is in `JvmInlineClassLowering.visitFunctionAccess`,
where we now store the substituted return type of the function as the
type of the call expression. Without it, the call could have a
meaningless type, e.g. some `T` which is inaccessible at that place, and
that could backfire in subsequent lowerings in codegen. For example, in
the `stringPlus.kt` test, it would prevent the code in
`FlattenStringConcatenationLowering.isStringPlusCall` from recognizing
and replacing the `String.plus` call, leading to a codegen exception.
Other changes are mostly cosmetics to make the code similar to
`visitFunctionReference`, and preventive optimizations for the case when
the substitution map is empty.
pyos