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
Otherwise, the assumption that coroutine codegen makes about every
inlined function already having the markers breaks and it is no longer
true that calls to inline lambdas do not require them.
- Since neither IrProperty nor IrField is Type Parameter container
using of proprty's type parameter in IrField related code leads to
creation of "hanging" type parameters which should be considered as
incorrect IR.
- Such code designed to be prohibited in LV 1.5
- The fix makes use of erased type in such case
where type parameter is expected.
In case derived class has a field with the same name as the base class,
RenameFieldsLowering previously tried to rename one of the fields by
adding the "...$1" suffix, which led to NoSuchFieldError.
It's important to have consistent pre_release flag values in the
current and bootstrap compiler. Otherwise, it's possible to publish
release compiler with pre_release artifacts (stdlib, for example) and
vice versa.
Once this test fails, the next step is to advance bootstrap compiler
Even if a function is known to be tail call because it's a compiler
generated bridge, the tail return might still need to be added in case
of Unit return type.
This is one example of a function replaced by a lowering after
AddContinuationLowering mentioned in the last commit: the lowering that
makes default stubs static is further down. Although this is not a
lambda, calling getOrCreateSuspendFunctionViewIfNeeded on it in the
inliner is fatal all the same.
* If `toArray` is inherited from Java, it may take an argument or
return a value of a flexible type, which looks nullable in IR;
* The returned array may also have `out` variance of the type
argument;
* `Array<T>` is not the same as `Array<Any?>` if `T` is neither `Any`
nor `in Something`, so presence of `toArray(): Array<T>` does not
mean we don't need to generate a new `toArray`.
Instead of generating overrides for getOwner/getName/getSignature in
each anonymous class representing a callable reference, pass them to the
superclass' constructor and store as fields. This occupies some small
memory but helps to reduce the size of the generated class files, and
will be helpful for adding further runtime information to callable
references, such as information about implicit conversions this
reference has been subject to.
Represent owner as java.lang.Class + boolean instead of
KDeclarationContainer, so that the unnecessary wrapping Class->KClass
wouldn't happen before it's needed, and also to make sure all callable
references remain serializable.
Note that the argument type where the "is declaration container a class"
is passed is int instead of boolean. The plan is to pass the
aforementioned implicit conversion information as bits of this same
integer value.
#KT-27362 Fixed
Instead of non-existing `kotlin.KotlinPackage`, which led to
NoClassDefFoundError as soon as reflection tried to call getOwner on a
builtin callable reference, use a reference to a new physical class
`kotlin.jvm.internal.Intrinsics$Kotlin`. This will allow to support
KT-17151.
Note that for API version less than 1.4, this will still lead to
NoClassDefFoundError, but this is not worse than the current situation
where it happens anyway.
Private $$forInline versions of public suspend functions should not
be mangled. (Note that there are no $$forInline versions of private
suspend functions, as those are effectively inline-only.)
Mikhail Zarechenskiy