The main benefit is that now lowerings and codegen are compiled in
parallel, which speeds up the build. Hopefully, this will also improve
incremental compilation in case of implementation changes because the
rest of the compiler (cli & tests) has no "api" dependency on lowerings
and codegen.
[JS] Node downloading for js ir integration kotlin test
[JS] Fix API of Promise
[JS IR] Promise symbol as lazy2
[JS] Support legacy compiler aftertest with promises
[JS IR] Generate finally for promised tests
[JS] Setup it tests for JS IR kotlin-test
Merge-request: KT-MR-5168
^KT-49738 fixed
This change adds shared 'debug.keystore' into the repository and
sets all the tests to use it.
Fixes issue when keystore was created by AGP 7+, but then consumed in
the test using lower versions of AGP.
^KT-45745 In Progress
Most of those tests are ignored, because IC is not supported properly
for compiler plugins. This commit is needed to prepare infrastructure,
fix current behaviour and collect main problems of IC with plugins
Check fail.txt files in new testdata for explanation of problems
* kotlinx.atomicfu compiler plugin for JS_IR
Support transformations of atomic operations introduced by the kotlinx.atomicfu library for the JS_IR backend. Compiler plugin is applied externally by the kotlinx.atomicfu gradle plugin.
* Apply compiler plugin for JS platform only
* New plugin test structure
* testGroupOutputDirPrefix changed
Those modules are:
- :compiler:fir:providers, which contains Fir and Symbol providers,
scopes, and different utilities used by them
- :compiler:fir:semantics, which contains different abstractions and
entities which are used in resolution and in checkers
- :compiler:fir:resolve, which contains all stuff related to resolution
and inference
There are two pros of this change:
1. It may increase gradle build, because it allows to compile :fir:resolve
and :fir:checkers modules in parallel
2. Logic of working FIR (scopes, providers, DFA logic system, etc) is
now separated from logic of resolution phases, so for example checkers,
which are depend on scopes physically will not be able to run resolve
in any way
Together with extracting codegen to a separate (unrelated) module in the
future, hopefully it'll speed up the build of JVM IR by making it more
parallel, and helping incremental compilation to avoid recompiling code
that depends on lowerings because of `implementation` dependency.
Alexander Udalov