The original approach required evaluating the existing input properties
of the task. This led to evaluation of the property values, and could
execute incorrectly if the task was not properly initialized at that
moment.
The new approach fixes that by first grouping options from each
subplugin by key and then adding disambiguating index suffixes.
Add 'kotlin.caching.enabled' flag to switch the caching for all tasks;
Rename and change semantics of cache support checks: make two instead
of one, `isBuildCacheSupported` and `isBuildCacheEnabledForKotlin`;
Remove FileOptionKind entries that are redundant at the moment;
Improvements in BuildCacheIT.kt and other refactoring suggestions from
the review
https://upsource.jetbrains.com/kotlin/review/KOTLIN-CR-1647
* Do not add the classpath elements to source to avoid them being
treated as task inputs without proper classpath normalization
* Move resolution of the classpath configuration to execution time
Introduce FilesSubpluginOption Special kind of SubpluginOption that
holds a list of files together with the kind of these files with respect
to the task.
Add a logic for handling such options and converting them into
task inputs.
Refactor CompilerPluginOptions: make it store subplugin options to be
able to add options from KotlinCompile to the kapt tasks.
Introduce WrapperSubpluginOption for encoded and complex options.
Remove pluginOptions from the Gradle inputs built from the
compiler args.
Do not cache Kotlin compilation with kapt1 enabled: since we are going
to drop kapt1 it anyway, there's no point in implementing
proper cache for it, so just disable the caching of the task in case
kapt1 is used.
Pull create/setup args functions up to CompilerArgumentsAware interface
Remove diamond-shaped CompilerArgumentsAware inheritance
Provide the default implementation for serialization in the interface
Make KotlinJsDce implement CompilerArgumentsAware
Implement the compiler args logic for Kapt & GenerateStubs tasks
* Fix the regex that could not actually find warnings
* Suppress an unused parameter warning in the test project
* Add allWarningsAsErrors to ExecutionStrategyIT
This commit makes IC react more granularly on these changes
Precisely, it marks dirty only kt-files that having lookups into
synthetic package built upon a changed layout-file
#KT-21622 Fixed
The problem may happen in case of multi-module projects:
If a Java class was effectively unused in one module (A),
but it's used in kt-files from the dependent module (B) then
we wouldn't track the changes of the class while compiling A
and don't recompile its usages in B.
It happens because now we track only Java classes that were
resolved by out frontend instead of all classes in the module
that would be more correct but it might be rather slow.
The idea is that whenever we see change in an untracked Java file
we start tracking the classes in it and for the first time we mark
all its content as changed.
Sergey Igushkin