Commit Graph

6 Commits

Author SHA1 Message Date
Ivan Kylchik c7435ba760 Replace all occurrences of WITH_RUNTIME with WITH_STDLIB
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
2021-11-17 15:26:38 +03:00
Alexander Udalov 1864716c83 Remove -Xnormalize-constructor-calls
Constructor call normalization is enabled by default since 1.3.
2021-09-02 22:11:22 +02:00
Mikhail Glukhikh 697006d782 [FIR2IR] Re-use receiver application logic in callable ref conversion 2020-03-30 16:23:10 +03:00
Mark Punzalan 9df2f69f09 [FIR] Disable failing blackbox codegen tests for FIR. 2019-11-19 11:00:09 +03:00
Dmitry Petrov 566b5856ec Constructor call normalization mode depends on language version 2018-07-27 09:52:29 +03:00
Dmitry Petrov c0a83c3c8a KT-19251 Process uninitialized stores in mandatory bytecode pass
See
https://youtrack.jetbrains.com/issue/KT-19251
https://github.com/puniverse/quasar/issues/280
https://bugs.openjdk.java.net/browse/JDK-8046233

Inline function calls (as well as try/catch expressions) in constructor
arguments produce bytecode that spills stack, and stores uninitialized
objects (created by 'NEW C', but not initialized by 'C.<init>') to
local variables. Such bytecode is valid according to the JVM spec, but
confuses Quasar (and other bytecode postprocessing tools),
and fails to verify under some (buggy) versions of JDK 8.

In order to avoid that, we apply 'processUnitializedStores' already
implemented for coroutines. It moves 'NEW' instructions after the
constructor arguments evaluation, producing code like

<initialize class C using Class.forName>
<evaluate constructor arguments>
<store constructor arguments to variables>
NEW C
DUP
<load constructor arguments from variables>
INVOKESPECIAL C.<init>(...)

NB some other expressions, such as break/continue in the constructor
arguments, also can produce "weird" bytecode: object is created by a
'NEW C' instruction, but later (conditionally) POPped from stack and
left uninitialized. This, as we know, also can screw bytecode
postprocessing. However, it looks like we can get away with it ATM.
Otherwise it looks like we'd have to analyze constructor arguments, see
if the evaluation can "jump out", and perform argument linearization in
codegen.
2017-09-27 12:38:52 +03:00