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
Both primitive int and wrapper type java.lang.Integer are represented by the
single type kotlin.Int in Kotlin, so inequality between the corresponding
KClasses was confusing here. To keep the old behavior, one may call 'k1.java ==
k2.java' instead of `k1 == k2`
#KT-13462 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 in KClassifier.createType and everywhere in the compiler, specify arguments
for the innermost type first. This is more convenient to use because generally
the construction/introspection of such type starts from the innermost class
anyway (i.e. something like generateSequence can be used, without the need to
call .reverse() in the end)
Its semantics were unclear and its javaType was implemented incorrectly (it
should have returned ParameterizedType with star projections for generic type)
- First parameter should have type of K instead of Any
- Special bridge should return second parameter if a key has wrong type
- Special bridge may throw an exception if defaultValue has wrong type
#KT-13209 Fixed
In an expression such as "Obj::class" where Obj is an object, it's fine to
consider Obj either an expression or a type and generate either
Obj.INSTANCE.getClass() or Obj.class correspondingly. However,
the former fails in the object's super constructor call because the INSTANCE
field is not yet initialized. Thus, we force generation of Obj.class in case
when Obj is an object.
Note that this has been reproduced in our project, see
KotlinMetadataVersionIndex
- Inline the usage of ExpressionCodegen#generateClassLiteralReference into
ClosureCodegen, simplify
- Support DoubleColonLHS.Expression in generateClassLiteralReference
- Substantially simplify KClass.java intrinsic by reusing
generateClassLiteralReference
#KT-13075 Fixed
#KT-12995 In Progress
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
Alexey Andreev