Android run-time verifier complains when there's any possibility that a
byte/short/char local variable could contain a value not fitting into the
type's limits.
This doesn't fix anything, just makes it easier to figure out values of what
types are used where. Progression increment is of its own type, which may be
different from asmElementType in case of Byte, Char, Short progressions
Instead of checking for overflow at the end of each iteration, calculate the
actual final loop parameter value before the loop, save it to the local
variable and at the end of the iteration check if the loop parameter is exactly
equal to this final value.
ProgressionUtil.getProgressionFinalElement() credits go to @geevee
#KT-3574 Fixed
Do not assert that resolvedCall is non-null, since getRangeAsBinaryCall can
return a BinaryCall that doesn't represent a range at all (as specified by the
comment in getRangeAsBinaryCall)
#KT-492 Fixed
For Byte, Char and Short ranges, promote the type of the loop parameter to int
to avoid overflows. For Int and Long ranges at the end of the loop over a
progression we now check if the new (incremented) value of the loop parameter
is greater than the old value iff increment > 0
#KT-492 In Progress
For Byte, Char and Short explicit casting from Int is removed -- loop parameter
is already stored in an Int anyway. For Int and Long comparison "i < end" at
the beginning of the loop is replaced to "i != end" at the end of the loop + a
special check for an empty loop
KT-2873: VerifyError on instantiating a local class inside a closure
KT-3210 Inline Class: CompilationException: Back-end (JVM) Internal error: wrong code generated java.lang.ArrayIndexOutOfBoundsException null
#KT-3389 Fixed
- use ResolvedCall where possible
- 'call' parameter to invokeMethodWithArguments was used only to generate
callee, e.g. in "A()" where A is an expression which can be invoke()'d.
In case of constructors and enum entry delegation specifiers there's no need
to generate callee, so 'call' is made Nullable with a subsequent assert
- remove generateJavaConstructorCall() method, since it did no useful work.
Java constructor invocation is broken anyway and needs to be fixed (KT-3532)
- minor code style / formatting issues fixed, several methods renamed to better
reflect semantics
- make several commonly used parameters ClosureCodegen's fields
- take an arbitrary strategy for closure function body codegen
- don't make extra binding context lookups
Instead of invokevirtual on FunctionImpl class, do invokeinterface on a
Function trait. This will allow to invoke functions on classes which don't
inherit from FunctionImpl classes.
Also rename the method to the more sensible name
Evgeny Gerashchenko