Do not treat var as alive just because current instruction belongs to an item range
in local variables table, but the item has different sort of type
As liveness analysis is mostly used in coroutines spilling,
not applying this change may lead that to problems on Android (see tests)
At first we try to resolve 'handleResult' just as last expression
in a lambda is first argument, then if results are unsuccessful
try resolve 'handleResult' with fake Unit expression
#KT-12969 Fixed
It works only for Java methods and it's purpose is Java overridability rules emulation,
namely distinction of primitive types and their wrappers.
For example `void foo(Integer x)` should not be an override for `void foo(int x)`
#KT-11440 Fixed
#KT-11389 Fixed
Do not generate stubs if there is no special bridge in the current class
- there are already Kotlin super class in hierarchy
- special bridge has the same signature as method itself
#KT-11915 Fixed
The problem is that
`override fun remove(element: E): CollectionWithRemove<E>`
seems to be illegal from Java's point of view, while it's OK for JVM
These declarations have the same signature (return type is isgnored)
- override fun remove(element: E): CollectionWithRemove<E>
- override fun remove(element: E): Boolean
When we meet such declaration we choose random declaration for fake override in synthetic class
that may lead to signature clash
Previously its call sites needed to determine if the receiver type should be
ignored (e.g. if the reference is to static member or nested class constructor,
or if it's a bound reference), and 3 of 4 callers did it incorrectly. Simplify
this by passing the DoubleColonLHS instance everywhere.
Also rename it to createKCallableTypeForReference
#KT-12738 Fixed
#KT-12751 Fixed
#KT-12799 Fixed
As well as all other kinds of expressions
While it's not necessary in a sense that 'for' loop can not be plain expression,
i.e. it can't be an argument for safe-call etc., but laziness is still very convenient property.
E.g. within attached test they were generated twice in case of last expression
of coroutine block, because coroutine related codegen part is built upon
assumption that all expressions should be generated lazy.
A lot of additional work was required to support them:
- Suspension points are being identified by two markers
instead of one pointing to suspend function call
- Approach with replacing return type of suspend function does not work anymore.
So we decode suspension return type as an argument for begin marker
- It became necessary to perform variables liveness analysis
(see comment in org.jetbrains.kotlin.codegen.coroutines.CoroutineTransformerMethodVisitor.spillVariables)
Denis Zharkov