* Caches are compared as files now. It is a more robust approach
than comparing strings with dumped contents. E.g previous test
ignored differences in keys ordering, because dumping caches to string
was added for comparing caches after incremental and non-incremental builds,
which cannot be compared without sorting keys (see KT-32674).
* Calling setUp/tearDown twice within the same test instance was
relatively hacky and fragile. Also it complicated adding new test cases.
Original commit: afa10cc125
Change the copyright from "JetBrains s.r.o." to
"JetBrains s.r.o. and Kotlin Project contributors"
Update only 2 lines copyright.
Original commit: 65244b4bea
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.
Original commit: ea4fc0fb6b
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).
Original commit: 175dd5679c
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
Original commit: 80c99eceff
We may need to run code generation when no source files are specified
for incremental compilation (to update caches & metadata)
Original commit: 97d3d38374
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
Original commit: ed86757817
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
Original commit: 75e59fdc46
Report about unsupported targets once per target type, show presentable
chunks list and don't show more then 5 chunks.
Example: "Native is not yet supported in IDEA internal build system.
Please use Gradle to build a, b, c, d, e and 10 other (enable 'Delegate
IDE build/run actions to Gradle' in Settings)."
#KT-26980 Fixed
#KT-28316 Fixed
Original commit: 62b0b3e4e9
1. Checking for COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS was moved to COMPILE_DAEMON_DEFAULT_RUN_DIR_PATH.
Looks like COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS was introduced incorrectly in 28a2d4727a.
Checking of this property was added in DaemonOptions.runFilesPathOrDefault, while DaemonOptions.runFilesPath was internally used in runFilesPathOrDefault and in many other places.
For example DaemonOptions.runFilesPath used to pass this option to daemon server.
So daemon was started with runFilesPath that ignores COMPILE_DAEMON_CUSTOM_RUN_FILES_PATH_FOR_TESTS.
2. JpsKotlinCompilerRunner._jpsCompileServiceSession was leaked between tests.
Fixed by extracting @TestOnly releaseCompileServiceSession() and calling it in tests tearDown()
3. The result of compileWithDaemon was ignored in compileWithDaemonOrFallback.
So, the fallback was never called, and the FAIL_ON_FALLBACK_PROPERTY was actually was never worked.
This was fixed. Also the message was improved to make it easier to find the original fail cause.
Original commit: 0c39358b5f
Implementation is similar to KotlinSourceRootProvider.
This workaround is required since ResourcesTarget.computeRootDescriptors
supports only JavaResourceRoots.
#KT-27622 Fixed
Original commit: dcc47fd8ef
Mikhail Zarechenskiy