This allows to replace dependency on 'js.frontend' with 'js.config', in
'kotlin-build-common' and 'daemon-common'. Also simplify some other
dependencies.
If an inline class is mapped to a reference type (or an array), it's Ok
to treat JVM view on a suspend function as returning a value of
corresponding inline class (although in reality it returns 'Any?'
because of COROUTINE_SUSPENDED).
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).
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.
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.
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
Alexander Udalov