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
This argument is useful in situations where the stdlib version which the
code compiles against is different from the one which is available at
runtime, such as the case of kotlin-gradle-plugin, which depends on the
compiler/stdlib compiled by 1.4, but may be executed in Gradle where
only 1.3.x is available.
#KT-37435
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.
The number of initializations of the `value` field before the live range
begins does not really matter so long as we insert a write of a default
value to the local if there were none.
We always set the $assertionsDisabled field based on the top-level
enclosing class. This means that for anonymous objects we have to
rewrite the call to Class.desiredAssertionStatus.
Somehow, I missed, that its 'create' function has bit arity, while
'invoke' does not. Thus, instead of directly passing arguments of
'invoke' to 'create', pack them into an array first.
If a part of an 'if' condition is an inline function call, we need to insert the original condition line after it. Otherwise, the debugger will think it is inside the inline function implementation. Obviously, this breaks stepping – instead of the 'if' body, we go on stepping through the inline function.
This commit fixes 'KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun' test.
This commit fixes the following tests:
- KotlinSteppingTestGenerated.StepOver#testSoInlineLibFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineIterableFun
- KotlinSteppingTestGenerated.StepOver#testSoInlineFunOnOneLineFor
Also:
* Do not rename public ABI fields
This includes backing fields for const, lateinit, @JvmField properties,
and instance fields for objects.
* FAKE_OVERRIDE declarations for static members of parent Java classes
Required to report cases when a Kotlin function accidentally overrides
Java class member.
parameters of inline function. Otherwise, it leads to AnalyzerException,
when inlined lambda contains try-catch block. The reason is simple:
in try block, we leave some variables on stack, while on catch block the
stack is empty. Spilling the variables before try block does the trick.
#KT-34708 Fixed
pyos