Inline functions require Kotlin compiler at least 1.3.50 if they were
generated by the compiler with API version >= 1.4. This is because since
API version 1.4, we've changed the generation scheme of parameter
nullability assertions and they now refer to methods from the standard
library which did not exist until 1.4. See
JvmSerializerExtension.writeInlineParameterNullCheckRequirement.
Some properties were calculated based on yarn and nodeJs version. So,
when version is changed properties were not updated. This change moves
calculation to the end of configuration phase and adds assertion to
ensure that version and other poperties are not changed
after configuration was done.
We pass compiler flags using an arg file if the compiler is executed
in a separate process because Windows limits maximal command line
length (see https://github.com/JetBrains/kotlin-native/issues/1999).
But for the compiler daemon we pass the args directly to the compiler
entry point method. So we can abandon using an arg file here.
We use an argument file to pass arguments to the K/N compiler.
Earlier each line of such a file was treated by the compiler
as a separate argument. But this logic was updated some time
ago and now content for this file is treated as a space separated
list of arguments.
This patch takes this into account at the Gradle side and quotes
arguments written to the arg file.
Issue #KT-35934 Fixed
* In the Kotlin/JVM tasks, move the compiler arguments setup logic to
a separate class, so that it can be reused by the Kapt tasks without
directly referencing the Kotlin/JVM tasks
* In the Kapt tasks, carefully capture the values using the Provider API
so that the task can be serialized for Instant Execution and then
deserialized and executed without relying on the project model
Issue #KT-35181 Fixed
For users that have Gradle's build cache [1] enabled, make NodeJsSetupTask
and YarnSetupTask cacheable to avoid the distribution archives being
downloaded again if they have been downloaded before by other builds of
other projects that apply the Kotlin plugin.
[1] https://docs.gradle.org/current/userguide/build_cache.html
Even if annotation processor classpath is the same, in case
individual entries change (e.g. bulding annotationo processor
from source), KATP should run non-incrementally.
Test: KaptIncrementalWithIsolatingApt.testUnchangedAnnotationProcessorClasspathButContentChanged
Just some syntax cleanup when visting the file.
Note: I was trying to understand why the output folders of kapt are creating so eagerly in a build, during configuration time indeed...(they should be created later, during execution).
Ilya Chernikov