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.
These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
Add a new module 'backend.jvm.entrypoint' which depends on psi2ir and
contains code that runs psi2ir + JVM IR backend with serialization
implementations.
Hopefully this will allow to compile these modules in parallel and
reduce the build time.
Extract a service interface out of ControlFlowInformationProviderImpl
and register its implementation in two "leaf" modules: 'cli',
'idea-core'.
This improves parallel build, since a lot of modules depend on
'frontend' but only these two modules reference the implementation and
thus depend on the full CFA implementation now.
Exclude modules where there are still warnings in an explicitly declared
variable `tasksWithWarnings`.
Also remove "-progressive" from compiler arguments in modules which are
built with non-latest language version, as the warning about that leads
to an error with -Werror.
The language/API version restriction here is to make sure the code works
with Gradle of earlier versions, but all versions of Gradle that we
support already depend on Kotlin 1.3+.
tools.jar from JDK has different public api on different platforms which
makes impossible to reuse caches for tasks which depend on it. Since we
can't compile against those classes & stay cross-platform anyway, we
may just exclude them from compile classpath. This should make tools.jar
compatible at least within one build of JDK for different platforms
In this mode, instead of analyzing files and generating bytecode for
them, compiler just saves imports of each file in JSON map of form
'<path to file> -> [<import1>, <import2>, ...]'
It is needed for some external tools, notably for Google3 toolchain.
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Dmitriy Novozhilov