The JVM IR backend code seems saner to me. The string concatenation
lowering for JVM IR calls the stringPlus intrinsic if there are
only two arguments. That leads to a lot less code:
```
load string
load argument
box argument
call Intrinsics.stringPlus
```
instead of
```
allocate StringBuilder
call StringBuilder.<init>
load string
call StringBuilder.append
load argument
call StringBuilder.append
call StringBuilder.toString
```
This will lead to more boxing, but a lot smaller code. We still
use StringBuilders in JVM IR if there are more than two strings
being concatenated.
even when arguments are to be rearranged.
Lambdas have no side effects, and storing them in temporary variables
prevents processing in the backend
(such as inserting continuation parameter in AddContinuationLowering).
E.g. in the following code
fun x() {}
inline fun f() { x(); g() }
inline fun g() { x(); f() }
the old implementation of inline cycle detection bailed out after
generating 3 calls of x() in each function, while the new one stops
after 2. In other words, code generation for a single function is no
longer reentered.
The fields containing crossinline lambdas should be package-private to
avoid generating synthetic accessors, which break object regeneration.
Note that the inline methods cannot actually be called, as call sites
will attempt to read the captured lambda from a field through a *copy*
of the local containing the object, so these reads will not be inlined,
causing an exception at runtime:
inline fun f(crossinline g: () -> Unit) = object : I {
inline fun h() = g()
// effectively `val tmp = this; return tmp.$g()`:
override fun run() = h()
}
f {}.run() // NoSuchFieldError: $g
This particular example can be fixed by reusing locals for receiver
parameters in IrInlineCodegen, but explicitly assigning `this` to
another variable and calling an inline method on it will break it again.
(This is only applicable to the JVM_IR backend, as the non-IR one fails
to generate `f` at all for some other reason.)
1. Search for increment function in range element type, not in inferred
induction variable type
(which can be inappropriate, e.g., 'Nothing' in case of 'continue').
2. Handle nested loops with shared exit labels
(generated by JVM_IR for KT-37370 case).
KT-37370 KT-37373
Mads Ager