* kotlinx.atomicfu compiler plugin for JS_IR
Support transformations of atomic operations introduced by the kotlinx.atomicfu library for the JS_IR backend. Compiler plugin is applied externally by the kotlinx.atomicfu gradle plugin.
* Apply compiler plugin for JS platform only
* New plugin test structure
* testGroupOutputDirPrefix changed
This method was used for coercing `Long` values to JavaScript
`number`. However, it caused issues when `Long` values were
concatenated to a string (see KT-8666, KT-26706).
for performance reasons: (1) the snapshots are too big, and (2) they are
usually updated only at the end of the task execution--in a failed task
run, they are usually unchanged and therefore don't need to be restored.
as we need access to the lookup tracker to compute classpath changes
more efficiently and reduce the size of the saved classpath snapshot.
The previous commit only changed the files' paths, this
commit actually updates the files' contents.
Note that classpath snapshotting still happens in Gradle artifact
transforms. (However, the previous commit also moved the code for
classpath snapshotting together with the code for classpath diffing as
they are closely related.)
In JS, RegExp can return a match before the specified start index,
if it has matched at that index, but it is in the middle of a surrogate
pair. Account for that when advancing to the next position after
a zero-width match so that it doesn't get to the middle of SP.
Currently JS/IR and WASM targets share this attribute.
This causes issues for HMPP projects on
Variant-resolution stage when both JS/IR and WAS published.
Given the fact that WASM compilation uses IR only it is logical
to exclude such attribute which should fix variant resolution in HMPP
Kotlin's compilation task outputs usually contains a lot of small files,
which is not so performant to copy as-is into new location. In this
change coping was replaced by using zip archive with no compression.
From my test I see around 2x performance improvement on doing task
outputs snapshot.
Further optimizations will be done via separate issue as they are
non-trivial and requires some changes on the compiler side.
^KT-49782 Fixed
Avoid adding ConfigurableFileTrees to sources as that causes
individual *.java files to be evaluated as sources roots. To
pass the dependency info, manual dependsOn is used, but in the
future SourceRoots should be fixed to carry the dependency info.
Not publishing this attribute fixes the consumers that don't set it.
Those may encounter either a conflict of Kotlin <= 1.5.31 rule on
{JVM, Android} -> Android vs Gradle rule
{standard-jvm, android} -> standard-jvm (causing disambiguation
failures). Or they may run Gradle < 7.0 which doesn't have
disambiguation rules for `org.gradle.jvm.environment` and therefore
treats it as an ordinary extra attribute, thus eventually preferring
variants which don't have it if no other disambiguation rule worked
(again causing disambiguation failures since some rules may prefer the
variants where this attribute *is* set).
Also set a "non-jvm" value of this attribute for non-JVM variants for
project-to-project dependencies in order to "align" them so that Gradle
doesn't prefer variants not marked with this attribute.
Extend the set of dependency resolution tests which check
compatibility of different kinds of Android & JVM consumers against
project and published library: add Kotlin 1.5.31 consumers, also check
consumption with different Gradle version than the one which did the
publication.
Issue #KT-49835
Yahor Berdnikau