In light classes mode, binding context may not have all the information
and this can fail, as for example was happening in the test
`diagnostics/tests/regressions/ea76264.kt`.
This only affects flags which are passed to
kotlin.jvm.internal.AdaptedFunctionReference. The only way it could lead
to changes in behavior is if it affected equals/hashCode of adapted
references. But it doesn't seem possible to construct a test where two
_different_ adaptations exist for a function reference to a
vararg-taking function, both of which use some sort of 1.4 function
reference conversion. Hence, no new tests are added.
It's used as a superclass for anonymous classes for adapted function
references. Its main feature is that it _doesn't_ inherit from KFunction
(as opposed to FunctionReference), as per the decision to postpone
reflection support for adapted function references in KT-36024.
#KT-36024 Fixed
Otherwise, the generated bytecode is unnecessarily suboptimal in some
(arguably weird) cases.
In the JVM backend, this was an accidental regression in #3260, as I had
not noticed that effectively inline-only functions were handled by a
separate branch in FunctionCodegen. In JVM_IR, I'm pretty sure the
redundant markers have always been there as `isSuspensionPoint` in
ExpressionCodegen never checked for effectively-inline-only-ness.
Specifically, this commit improves the stepping behavior of the IR
backend around functions with defaults.
- Improved line numbers in the default handler itself for better
stepping when inlined.
- Improved source information on default arguments
- Improved test coverage of stepping behavior in old and IR backends.
Improves the stepping behaviour around inline methods with default
arguments. In particular, we now accurately step through the
evaluation of default arguments, but do _not_ spuriously show the exit
from the $default handler.
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.
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).
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.
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
Dmitry Petrov