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.
Local returns normalization can generate POP instructions.
These POP instructions can drop functional parameters, as in KT-17590,
and should be processed in markPlacesForInlineAndRemoveInlinable just
as other POP instructions.
KT-17590 conditional return in inline function parameter argument causes compilation exception
It never terminates, so the corresponding value on stack can't be used.
However, if this happens in an inlined lambda argument, the inliner is
unable to remove the corresponding ALOAD instruction (because default
handler never terminates, and thus corresponding ALOAD is not used for
lambda invocation).
KT-17573 try-finally expression in inlined function parameter argument fails with VerifyError
When a try-catch expression is passed as an argument to the inline
lambda parameter, lambda variable on stack is spilled and restored in
several different locations (1 for try-block, 1 for each catch-blocks).
So it's possible that lambda to be invoked comes from multiple loads,
all of which should have the same "root" lambda parameter.
In cases like KT-17384, where 'break' or 'continue' happens in an argument
to an inlined lambda call, fix-stack transformation sees corresponding
ALOAD for lambda, and inserts corresponding POP instruction before jump.
However, this ALOAD is later removed during inlining.
So, we should also remove the related POP instructions.
Local declarations obtain names prefixed with outer function's name.
Only simple name (i.e. without mangling) of outer function used
in this case. This raises a problem in case of inline functions
with object literals. Currently, they are not copied, but exported
from module. Consider two inline functions foo with different
signatures, both declare object literals. In this case both literals
are exported as foo$f, so only one will be accessible from outside.
This is required to make translateAndAliasParameters
behaviour a little more clear.
Also, fix destructuring declaration translator to use parameter aliases
from TranslationContext, when possible.
Refactor some utility functions that take consumer of JsStatement
to return actual statements, so that caller now responsible
for putting these statements to corresponding lists.
Mikhail Glukhikh