Remove unnecessary non-null parameter checks inside static delegate methods
created for @JvmStatic companion object methods. Allows function generation
strategy decide if such checks need to be injected.
#KT-7188 Fixed
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+.
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'.
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()
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
Support Comparable#compareTo for boxed primitive in redundant
boxing/unboxing analysis, along with CHECKCAST to java.lang.Comparable.
Note that we can do that for Float and Double, too, because
Float#compareTo(Float) and Double#compareTo(Double) are delegated to
Float#compare(float, float) and Double#compare(double, double),
respectively.
Fuse specialized comparison for integers with conditional jumps
if possible (both for Comparable#compareTo and Intrinsics#areEqual).
#KT-11959 Fixed
- A LINENUMEBER node is "dead" if the corresponding instruction interval
contains at least one "dead" bytecode instruction
and no live bytecode instructions
- Observable local variable lifetimes should be taken into account
when determining if a NOP is required for debugger.
Using basic constant propagation (only integer constants, no arithmetic
calculations), rewrite conditional jump instructions with constant
arguments.
This covers problem description in KT-17007.
Note that it also works transparently with inline functions.
Partial evaluation is required to cover more "advanced" cases.
As a side effect, this also covers KT-3098:
rewrite IF_ICMP<cmp_op>(x, 0) to IF<cmp0_op>(x).
In code like 'a?.b == 42', we can immediately generate equality
comparison result when receiver is null (false for '==', true for '!='),
since the primitive value is definitely non-null.
Otherwise unnecessary boxing/unboxing is generated to handle possibly
null result of 'a?.b'.
NB: for-in-until loop is generated as precondition loop, because the
corresponding range is right-exclusive (and thus we have no problems
with integer overflows).
Dmitry Petrov