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
Previously this files was stored in /src directory and was included in
resources mainly by SourceSet.projectDefault from sourceSets.kt:
val processResources = tasks.getByName(processResourcesTaskName) as ProcessResources
processResources.from("resources") { include("**") }
processResources.from("src") { include("META-INF/**", "**/*.properties") }
Also there are some custom rules like this:
resources.srcDir("../idea-analysis/src").apply { include("**/*.properties") }
resources.srcDirs("idea-repl/src").apply { include("META-INF/**") }
All this rules are synthesized in script
https://github.com/snrostov/kotlin-migrate-resources/blob/master/src/main/kotlin/main.kt
This commit created using that script. See README.md for more details on
script.
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
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 220fab0d3f.
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.
Implementation is similar to KotlinSourceRootProvider.
This workaround is required since ResourcesTarget.computeRootDescriptors
supports only JavaResourceRoots.
#KT-27622 Fixed
In this test only lookups caches are invalidated and only in first step.
module4 shouldn't be rebuilt since is compiled in step 1 and it is independent of all dirty modules.
Previously this module was rebuilt because of #KT-27044 which is fixed
by 5232f08
#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.
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.
Vyacheslav Gerasimov