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.
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.
Note: this currently results in invalid IR (but valid bytecode) if the
@JvmStatic function is imported, because its IR representation is
unlowered and therefore has a dispatch receiver, but the call will not.
In general case parameter type could differ from actual default lambda type.
E.g.: fun inlineFun(s: (Child) -> Base = { a: Base -> a as Child}),
where type of default lambda is '(Base) -> Child'.
In such case we should find somehow actual invoke method in bytecode knowing
only name, number of parameters and that's actual invoke is non-synthetic
regardless of bridge one.
#KT-21946 Fixed
Mads Ager