This should be helpful when frequently testing changes in JS BE.

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.

Only top-level types on fields, methods' return types and
value parameters are supported to catch-up how class-files are loaded
in IntelliJ (see IDEA-153093)

NB: this commit also affects
ForeignJava8AnnotationsNoAnnotationInClasspathWithFastClassReadingTestGenerated
that were failing before

 #KT-20016 Fixed

Prior to this change USE_FAST_CLASS_FILES_READING actually
has not worked because the flag is being read in the KotlinCoreEnvironment
constructor :man_facepalming:

Some of them are expected to fail since neither IntelliJ class reading
nor our fast class reading can read annotations on type arguments

 #KT-20016 In Progress

- Apply default qualifiers to type arguments if they contain TYPE_USE
in applicability list
- Read TYPE_USE placed default qualifier annotations

 #KT-19592 Fixed
 #KT-20016 In Progress

Before this chanhe, these annotations are simply ignored, but they should
preserve flexibility in case of enhanced nullability obtained from
enclosing default qualifier

 #KT-20158 Fixed

 #KT-20131 Fixed

When IC is on and new Kotlin class is referencing
new Java class, new Kotlin file is compiled twice,
because JPS thinks new Kotlin class is affected by
new Java class (see https://youtrack.jetbrains.com/issue/KT-20318).

This does not happen when IC is off, and KotlinBuilder
requests chunk rebuild (see previous commit).

I decided to remove the reference, because the issue
is now known, and the reference is non critical for the test.

Otherwise unexpected compile error might happen,
when there are Groovy files, but they are not dirty,
so Groovy builder does not generate source stubs,
and Kotlin builder is filtering out output directory
from classpath (because it may contain outdated Java classes).

Previously the issue was not detected,
because it was not possible to turn off the IC completely (in JPS),
only switch to the legacy IC.

    #KT-20138

 See more in KT-20171

 See more in KT-20171

Don't convert local variables to fields of coroutine object
when variable is both used and defined in a single block.

See KT-18548

See KT-18010

So #KT-20417 Fixed