Without this commit, JVM name mapping logic in BE does not work for FIR,
because FIR cannot use old BuiltInsPackageFragmentImpl descriptor.
In this commit we add our own implementation thus fixing
a pack of FIR black box tests.
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.)
simon.ogorodnik