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.
Library methods such as 'listOf' are resolved
to have the package fragments as their parents,
but JVM expects their containing file classes as parents.
This fix generates those file classes and
uses them as parent replacements for such library methods.
Currently FirThisReceiverExpression of instance methods are translated
to references of the class' thisReceiver,
not the method's dispatch receiver,
which causes problems with IrFrameMap::typeOf,
as the class' thisReceiver is not in the typeMap.
This commit translates non-qualified "this" references of
instance methods to references of the methods' dispatch receiver.
Three modes:
- 'disable' (default): normalize constructor calls in coroutines only
(required because uninitialized objects can't be stored in fields),
don't insert additional code for forced class initialization;
- 'enable': normalize constructor calls,
don't insert additional code for forced class initialization;
- 'preserve-class-initialization': normalize constructor calls,
insert additional code for forced class initialization.
See
https://youtrack.jetbrains.com/issue/KT-19251https://github.com/puniverse/quasar/issues/280https://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.
vladislav.grechko