Our JPS and Gradle plugins handle
recompilation of multifile classes differently.
JPS plugin delegates handling to the JPS itself,
which tracks dependencies via bytecode,
and marks classes as dirty when they are affected.
So in JPS other parts of multifile classes are recompiled only
when a part's signature is changed.
In Gradle plugin we handle recompilation ourselves in
simpler way: any change in any part leads to a recompilation
of all parts of the same multifile class.
In future we should improve our Gradle plugin, but for now
I'm changing the test so that both JPS and Gradle tests
recompile all parts.
Also the dummy function is added to make sure that we
don't blindly recompile everything when a part is changed.
JVM compiler loads scripting plugin by default,
which in turn performs script template discovery
in compile classpath.
Classloading and template discovery takes noticeable
amount of time in JPS tests, because of
relatively big number of short compilations.
Disabling scripting plugin in most JPS+JVM tests
speeds up JPS tests by ~8% compared to the result before all
optimizations.
This speeds up JPS tests by ~16% compared to the result before all
optimizations. The speedup comes mostly from avoiding re-reading jar
files (like kotlin-stdlib.jar).
After each test we rebuild everything,
then we compare incremental caches and output
with caches and output after rebuild.
For some reason we did rebuild and comparison
twice per test. This seems excessive.
Removing the second rebuild speeds up JPS tests by ~15%
compared to the result before all optimizations
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
Up-to-date check is very heavy for intellij repo due to artifact size.
If module directory in repo is written only by one task we can assume
that task if up-to-date if target directory exists.
Previously `findJavaRootDescriptor` was return source root for random
module. This cause build errors for mpp (same file may appear in
multiple source roots of common and platform modules)
#KT-28988 Fixed
Nikolay Krasko