Function references are now equal if they refer to the same function,
and if the parameter/return type adaptation, which happens when a
reference is used where some function type is expected, is exactly the
same. This includes the number of expected positional parameters (which
can be affected by defaults/varargs), whether the coercion of vararg
parameter to Array type happened, and whether the coercion of return
type to Unit happened.
#KT-37543 Fixed
If `mapLineNumber` was called in non-monotonic order, e.g. N then N+2
then N+1, the first two calls created a range that spans [N; N+2] but
the third call did not reuse it.
For a class literal Type::class we are resolving Type as a constructor,
getting all diagnostics (about missing arguments, for example) and then
just not committing this trace with errors
#KT-37626 Fixed
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.
Victor Turansky