It's necessary for proper recovering of classId by plain string JVM descriptor when loading annotations
See FileBasedKotlinClass.convertAnnotationVisitor
Related tests are already exist in loadJava, but they stopped working
after the recent changes:
nested classes are not found anymore by name with '$' symbol
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
- 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
Otherwise linenumber for previous instruction will be used in debugger. That can lead to error stepping
because it might be line that isn't reachable on current iteration.
#KT-13059 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)
Denis Zharkov