FixStack transformation divides on phases:
- Fixing stack before break/continue
- Fixing stack for inline markers/try-catch blocks
After the first stage all ALWAYS_TRUE markers are replaced
with simple GOTO's and if we're skipping break/continue edges
we won't reach the code after while (true) statement.
At the same time it's fine to not to skip them in the second phase
as the stack for them is already corrected in the first phase
#KT-19475 Fixed
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.
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
1. Analyze method node with fake jumps for loops to make sure that
all instructions reachable only through break/continue jumps are processed.
2. Fix stack for break/continue jumps.
3. Drop fake jumps for loops, analyze method node again.
4. Fix stack for try/catch and beforeInline.
Revert changes for "tolerant to uninitialized values" in OptimizationBasicInterpreter:
this approach doesn't converge for some specific cases where local variable is reused
(e.g., in several inlined functions - see https://youtrack.jetbrains.com/issue/KT-15112).
Instead, treat fake always-false conditional jump in the beginning of the post-condition loop as a "reference point" for stack on loop break / continue.
This requires an extra abstraction layer in FixStackAnalyzer, since we can't perform fine-grain manipulations on Frames
(such as "combine frame C from local variables of frame A and stack of frame B").
NB additional NOPs will be generated for post-condition loops.
Should make a separate bytecode postprocessing pass to get rid of unnecessary NOPs
(several YT issues for perceived quality of the generated bytecode are about such NOPs).
when a method (or a property getter) returns Nothing, emit
ACONST_NULL
ATHROW
after a call so that class files verifier knows that this is an exit point in a method.
Note that if an inline method returning Nothing throws an exception explicitly
(or via a chain of inline methods), this code will be deleted by DCE.
Parse TryCatchBlockNode's in generated bytecode, infer stack save/restore points.
Save stack to local variables before 'try'.
Restore stack after the beginning of try-block, catch-block, and default handler.
Integrate before/after inline markers rewriting (otherwise it'll break our stacks).
#KT-3309 Fixed
- generate fake jump instructions so that we can always analyze stack depths
- fix stack before break and continue by dropping excessive elements (e.g., *a*.foo(*b*, c?:continue))
- Analyzer rewritten in Kotlin, with more flexible control of CFG traversal
#Fixed KT-3340
#Fixed KT-4258
#Fixed KT-7941
And String.length as well.
This is done for JVM interoperability: java.lang.CharSequence is an open class
and has a function 'length()' which should be implemented in subclasses
somehow.
A minor unexpected effect of this is that String.length() is now a compile-time
constant (it wasn't such as a property because properties are not supported in
compile-time constant evaluation)
#KT-3571 Fixed
This is not something that needs to be intrinsified. Note that compiler
optimizations are still possible and the fact whether 'indices' is a member or
an extension is irrelevant to the optimizer
Denis Zharkov