In Kotlin 1.3+, assignment to the for-in-array loop range variable in
the loop body doesn't affect loop execution (as if it was a loop on an
array iterator, or some other container).
#KT-21354 In Progress
#KT-21321 In Progress
When the enum entry requires a specific class, its constructor should
invoke proper supertype constructor (from the corresponding enum class).
Corresponding resolved call should be passed from the front-end in
CONSTRUCTOR_RESOLVED_DELEGATION_CALL slice.
In case of enum entries without explicit supertype initializer, this
information was missing.
See KT-21493
It's hard to maintain staticRef in cached AST. In fact, we don't need
it in this optimization. We'll get excessive names in used set,
which is ok: non-function names don't matter, they'll be simply ignored.
One possible concern: there's more chance to get name same to
some function's name and it won't be removed. First, it's not fatal,
it won't break the code (but put some excessive code that will likely
be removed by DCE). Second, there's same chance of two functions
having same names, and we manage to avoid this (otherwise we'll get
many problems).
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
If the range expression is not a local variable (which can be updated in
the loop body affecting loop behavior, see KT-21354), we can cache the
array length, thus turning a for-in-array loop into a simple optimizable
counter loop.
#KT-21321 In Progress
Existing code for receiver generation accidentally worked in most cases
for object members imported by name. However, it generated strange
bytecode (such as
GETFIELD AnObject.INSTANCE
GETFIELD AnObject.INSTANCE
POP
), and worked incorrectly for augmented assignments.
#KT-21343 Fixed Target versions 1.2.20
This is more correct because it'll allow the incremental package
fragment to be deserialized with the same analysis flags as the changed
sources. Currently it doesn't seem possible to add a reasonable test for
this fix because there are no flags relevant for JS except for
skipMetadataVersionCheck, which is experimental and thus doesn't require
a test
Dmitry Petrov