JPS does not remove output files for files marked as dirty
for current iteration. This is a problem for adding complementary files
during JPS MPP IC.
If output files are not removed, the compiler might raise an error
for duplicated actual declarations.
Original commit: 06275a201c
Lookup storage output files could differ for projects
with different absolute paths.
This happened because, paths for lookups were
relativized only before writing to the underlying storage.
Storing absolute paths in a hash table could
result in different order of adding files to the lookup storage.
This commit fixes the issue by sorting lookups and files in
LookupStorage#addAll
#KT-32674 Fixed
Original commit: a4c62d156f
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
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
#KT-27868 Fixed
Previously given dirtyFiles was removed from complementaryFilesMap
exactly on call of clearComplementaryFilesMapping. This causes fail
of next build in case of compilation error of previous build on JPS
(since complementary files not known on second build). The right way
to do it is removing (replacing) them only after successful
build.
This was working on Gradle since Gradle rebuilds whole module (project)
in case of build error.
Original commit: f70d01f657
Exceptions were catched in `KotlinCompilerRunner.runCompiler`.
When the method from superclass is not used in
`GradleKotlinCompilerRunner`, the superclass does not make much sense
anymore, so I turned it into util object.
Original commit: a41c2d759a
Alexey Tsvetkov