All reified type parameters referenced by objects in non-default lambdas
are from outside the inline call, thus they cannot be substituted yet.
This means if the only reason for object regeneration is reification,
then regeneration isn't actually necessary.
E.g. in this code:
inline fun <reified T> f(x: () -> Unit) = x()
inline fun <reified V> g() = f<V> { { println(V::class.simpleName) }() }
we first inline the lambda into f(), then inline f()-with-lambda into g().
Because the object inside the lambda captures nothing from outside g(),
the original class can be used both times.
This brings the JVM_IR backend into complete compliance with KT-28064.
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.
Exclude jdk files form libraries input. Instead add jdk major version
to inputs. JavaCompile task acts same to ignore fluctuations in JDK
implementations since api should remain same
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.)
pyos