If the loop end value is a compile-time constant (best we can do now),
and it is safe to iterate over a given range using "naive" for loop
(using '<=' or '>=' in loop condition),
generate such loops for Longs and Chars as well Ints (Bytes, Shorts).
For-in-string loop can be generated using specialized 'length' and
'charAt' method calls, and with cached string length.
Note that update of the string variable in loop body doesn't affect
loop execution semantics.
#KT-21322 Fixed Target versions 1.2.20
Constant expressions are inlined if they do not depend on non-inlineable
vals.
Java constants are always inlined.
Kotlin constants are inlined in LV 1.1+.
Stack should be spilled before inline function call and restored after
call only if one of the following conditions is met:
- inline function is a suspend function
- inline function has try-catch blocks
- inline function has loops (backward jumps)
Note that there're quite some "simple" inline functions in Kotlin stdlib
besides run/let/with/apply. For example, many string operations are
implemented as inline wrappers over Java method calls.
Lateinit local vars are guaranteed to be non-null after store.
So we mark such stores as storing non-null value
(could be useful for some other constructs, too),
and optimize null checks accordingly.
In short, some of the bytecode analyzers assume that there could be
no stores instructions into parameter vars with value of different
types (even when the value type is a subtype)
See the issue for details
#KT-19713 Fixed
This makes sense for non-floating-point primitive type
(boolean, char, byte, short, int, long):
floating-point types use specialized versions of 'areEqual'.
Dex ignores subsequent line numbers for same instructions and interprets
instruction after inline as if they were inlined. This makes debugger
behaves as if there's nowhere to stop on line with breakpoint.
This also makes stepping through inline function consistent with
non-inline analog. In both context debugger now stops on '}'.
#KT-18949 Fixed
#KT-17120 Fixed
It's safe to upcast integer types to Long,
floating-point types to Double.
So we don't have to create a range instance for cases such as
fun testLongInInt(x: Long, a: Int, b: Int) =
x in a .. b
which is equivalent to
fun testLongInInt(x: Long, a: Int, b: Int) =
x in a.toLong() .. b.toLong()
DUP_X1; POP = SWAP
p1_a; p1_b; SWAP = p1_b; p1_a
where p1_a, p1_b are instructions without side effects pushing value of
size 1 on stack.
E.g.: ACONST_NULL; ALOAD 0; SWAP = ALOAD 0; ACONST_NULL
NOP; NOP = NOP
Reuse StringBuilder instances for nested subexpressions.
(NB StringBuilder instance for string template with a string
concatenation inside an expression entry, such as `"${"a" + "b"}"`,
will not be reused, although that doesn't seem to be a real-life issue).
#KT-18558 Fixed Target versions 1.1.4
#KT-13682 Fixed Target versions 1.1.4
Join adjacent strings literals, escaped strings, and constant values
(in a language version that supports const val inlining).
Use StringBuilder#append(char) for single-character constants
(e.g., " " in "$a $b").
#KT-17280 Fixed Target versions 1.1.4
#KT-15235 Fixed Target versions 1.1.4
These values can't be read after going out of scope.
JVM implementation can take care of such object references on its own.
Ref objects for captured variables are not different from any other
objects stored in local variables, so there's really no reason to
nullify these references explicitly.
#KT-18478 Fixed Target versions 1.1.4
