Backend: If kotlin class extends kotlin.collection.List
write it as it's super interface (light class mode only)
IDE: Provide wrapper classes to java resolve
that try to emulate backend behaviour
For example if kotlin class implements kotlin.collections.Map,
we provide a superinterface that has abstract 'getEntries' method
and 'entrySet' method that is considered default.
In reality all those methods are generated in the class itself.
In IDE supporting this case without hacks is not feasible performance-wise
since kotlin.collection.* may not be an immediate supertype and we need
to compute all supertypes just to calculate own methods of the class
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
Previous test had an inline setter that didn't produce any effect,
thus, corresponding code was removed by new DCE.
Make sure that changes made in the inline property are caught up by IC.
- 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.
It is actually more meaningful than just "coercion to unit elision":
it removes instructions without side effects with results that are
unused (popped from the stack).
- 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'.
Mikhael Bogdanov