Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
The `kotlin-test` dependencies are left untouched as changing them affects publications, thus these versions are independent from the used inside our build
#KTI-1349 In Progress
This commit prevents language version increase due to bootstrapping
problems. Compiler version X attempts to build the project with the
current version X+1 -> warning about progressive mode cannot be enabled ->
error due to -Werror -> build failure.
The command line argument parser is using between 0.25s and 0.5s
(depending on platform) on finding annotated properties. This fix
replaces the slow kotlin reflection with java reflection, which is an
order of magnitude faster.
#KT-58183 Fixed
The customization was added for compatibility with Gradle. That isn't a problem anymore, as we don't use it from KGP and soon we will eliminate the direct dependency on kotlin-compiler from KGP.
Those classes mainly include KotlinCoreEnvironment and its dependencies
This change is needed for two reasons:
1. Splitting of some common configuration of compiler from logic of CLI
makes code structure more clean
2. There is a need to add dependency on `:analysis:analysis-api-standalone`
to `:compiler:cli`, because FIR analogue of AnalysysHandlerExtension uses
services from it. But the problems is that standalone AA itself depends
on classes for compiler configuration, which leads to circular
dependency between those modules. Extracting configuration to
`:compiler:cli-base` solves the problem
Reasons:
1. Those modules don't use this dependency
2. Unbundled JPS feature in IDE downloads all transitive dependencies of
kotlin-dist-for-jps-meta => downloads org.jline and puts it into dist
which is not needed
This will be used for two purposes:
1) call lowerings and codegen separately from
KotlinToJVMBytecodeCompiler to support cyclical module dependencies
(KT-49575)
2) split lowerings and codegen into separate modules
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
Alexander.Likhachev