The main reason is avoiding complicated operations like
dup + dup_x2 + pop2 for instances obtained by NEW instruction.
Otherwise it leads to problems in performRefinedTypeAnalysis
because code there has a sensible assumption that NEW instances
can be only dupped or stored into a local (rare cases)
#KT-17457 Fixed
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
These changes has been introduced in c3a032ea0b
to support new scheme for named functions
At the same time they can be avoided by generating some additional
code/accessors in the anonymous classes for coroutine state
Now we cannot simply remove introduced API because of bootstrap problems
#KT-17898 Fixed
Precondition loops are better optimized by HotSpot
(and, quite likely, by ART).
Also, we generate more compact bytecode that way.
KT-17903 Generate 'for-in-indices' as a precondition loop
- 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.
- Turn some const conditions into non-const conditions
- Make sure inlined const values are used where required
(otherwise they are eliminated by POP backward propagation)
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'.
The problem was that the resume call (from doResume) for open members
was based on common INVOKEVIRTUAL to the original function
that lead to the invocation of the override when it was expected
to be the overridden (after super-call being suspended)
The solution is to generate method bodies for open members into
the special $suspendImpl synthetic function that may be called
from the doResume implementation
#KT-17587 Fixed
The reason is that when it gets captured into the field
having name $$continuation inliner fails with an exception
as it skips fields starting with '$$'
At the same time it doesn't really matter how to call
that parameter because it's only visible in Java
#KT-17585 In Progress
#KT-16603 In Progress
The main idea is to leave all the inline functions as is, without
state machines (but keeping suspend-calls markers) and
determine whether we need a state machine from the bytecode
after inlining into a non-inline function
#KT-17585 In Progress
#KT-16603 In Progress
#KT-16448 Fixed
Friend modules should be provided using the -Xfriend-modules flag
in the same format as -libraries. No manual configuration required for
JPS, Gradle and Maven plugins.
Friend modules could be switched off using the -Xfriend-modules-disabled
flag. Doing that will
* prevent internal declarations from being exported,
* values provided by -Xfriend-modules ignored,
* raise a compilation error on attemps to use internal declarations from other modules
Fixes #KT-15135 and #KT-16568.
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).
#KT-10397 Fixed
According to JVMS (p. 4.3.4) inner classes should be separated with `$` in generic signature.
Note that in Java, inner types separated with `.` after first parameterized type, and now we preserve the same behaviour. See tests for clarification.
Alexey Andreev