Basically they're built upon basic coroutine tests, but for each of them
different interceptResume implementation are injected
(currently there are 12 of them).
It might be more simple just to generated additional testData, but I see this
more problematic in a sense of further maintenance
Note that all tests add idempotent 'interceptRun' operators,
which just execute given lambda in the current thread
#KT-14891 Fixed
The main benefit are class-files sizes for them
(not repeating the same declaration for each coroutine)
Also it helped to simplify coroutine codegen code a little
Note that controller/label field become non-volatile (see KT-14636)
#KT-14636 In Progress
Replace coercion from VOID with call 'pushDefaultValueOnStack'
It's necessary because coercion of VOID to java/lang/Object ends with Unit instance on stack
that makes variables spilling algorithm thinking that variable is Unit
#KT-13409 Fixed
Before this change everything works just fine for 'handleResult' methods
accepting non-Unit parameters
For other cases the same coercion-to-unit strategy is in plain lambdas:
- if last statement is not Unit type, execute it, pop from the stack, then put Unit instance
- for 'return@label' (no expression) just put Unit on the stack
#KT-13531 Fixed
It fixes VerifyError with coroutines on Dalvik happening because of
variables spilling before/after suspension point
BasicInterpreter from ASM does not distinct 'int' types from other
int-like types like 'byte' or 'boolean', neither do HotSpot and JVM spec.
But it seems like Dalvik does not follow it, and spilling
boolean value into an 'int' field fails with VerifyError on Android 4,
so it's necessary to distinct int types for variables spilling
#KT-13289 Fixed
As well as for other kinds of expressions
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 lazily
Also add a test about unary postfix increment/decrement
#KT-13156 Fixed
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
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.
Stanislav Erokhin