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
Pass computed list of changed classpath names to KAPT instead
of relying on the history files to be computed by stub generation.
Also, stop generating classpath history changes during the stub generation.
This commit does not compute the actual changed classpath entries,
and that will be done in the following commits.
#KT-23880
Add support for incremental annotation processors in KAPT. These
processors conform to https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing
specification.
Support is provided by using javac compiler APIs and
recording the source file structure. At runtime, processors
are instrumented with custom Filer that is used to keep track of generated
files. In order to support classpath changes, stub generation task is
used to generated a list of changed FQCNs, and this is simply used by KAPT.
Both worker and non-worker mode are supported.
#KT-23880
With gradle > 5.0 `publish()` helper call should be done before
`noDefaultJar()` or any other artifact hacks, otherwise singing plugin doesn't sign any jars
#KT-12700 Fixed
To turn build reports, add 'kotlin.build.report.enable=true' to
gradle.properties file
(or pass it in CLI via`-Pkotlin.build.report.enable=true`).
By default build reports are created in
`rootProject/build/reports/kotlin-build`.
Build report dir can be customized via `kotlin.build.report.dir`
property.
On windows using a project's root
as a working directory for the daemon
seems to prevent removing the directory
when the daemon runs.
Different projects may share an instance of the daemon,
so the issue will be present only in a project
which started the daemon.
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.
The class is used on both server and client, but it was defined in
server module.
Gradle plugin worked, because all classes are present in kotlin compiler
embeddable, but the code was red in IDE (which is correct because
Gradle plugin does not depend on daemon server module).
Declare AnalysisFlags in module 'frontend', and JvmAnalysisFlags in
module 'frontend.java', to avoid leaking Java-related logic to common
compiler code
Roman Artemev