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
#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
Superclass of closures should now be FunctionImplN instead of FunctionN. Since
these -Impl classes are needed only in JVM, the corresponding descriptors and
types are created in the back-end only.
Evgeny Gerashchenko