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.
The Android build pipeline can extract embedded proguard configurations
from dependencies and merge them automatically. This adds a conservative
proguard configuration to the kotlin-reflect JVM artifact in support of
that. This focuses mostly on just retaining what's necessary for
kotlin-reflect's own functionality to operate, but could be expanded if
community feedback discovers other good candidate rules.
With this in place - most Android projects using R8 or Proguard should
Just Work™️ with kotlin-reflect.
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
This avoids having both libraryJarWithoutIr and default jar artifact,
which points to the same path as libraryJarWithIr, in the dependent
projects' classpath.
Use libraryJarWithIr instead.
For local builds where libraryJarWithIr doesn't contain any IR, this
should have the same effect.
jar task is disabled, but its artifact is still used through
the runtime configuration in the other projects.
In fact, dependent projects get both
libs/kotlin-stdlib-js-1.3-SNAPSHOT.jar
lib/dist/kotlin-stdlib-js-1.3-SNAPSHOT.jar
in their classpath.
However the former artifact is built with libraryJarWithIr task after
jar task is skipped. This leads to a situation during the parallel build
that a dependent project tries to read that artifact
when libraryJarWithIr task writes it.
This commit adds a dependency edge between the disabled jar and custom
libraryJarWithIr tasks, so that the artifact is ready by
the moment jar task has finished.
This option has no effect on the production code. But in a custom
scenario of a local bootstrap, where the compiler is replaced with the
one where JVM IR backend is enabled by default, this option allows to
switch back to the old backend.
All of these arguments (except the one for compiling experimental
coroutines) are supposed to go away as soon as we fix related problems
in the JVM IR backend.
* 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
Ilya Chernikov