Change NativeDistributionCommonizerCache from "decorator" pattern to
be used as composition in related GradleTask. This allows to decouple
cache from actual commonizer instance. Allowing it to be stored in
Gradle Configuration Cache. Since Commonizer instance is created only
during execution phase.
Don't serialise `Lock` instance as Configuration Cache. Instead,
reinstantiate it everytime after deserialization.
Gradle Configuration Cache writer serialises objects that implement
java.lang.Serializable interface. SynchronizedLazyImpl does implement it
by initialising value before serialization.
This can cause issues for GCC because after initialisation value
can contain unsupported entities that Gradle can't save as
Configuration Cache.
Gradle can serialise lambdas so UnserializableLazy implementation
benefits from it.
* Replace `project.provider` that captures `project` inside lambda to
`lazy`. This is a workaround of this bug gradle/issues/20820
* Lift all the settings-like properties that was used during execution
to configuration phase
^KT-43293
Remove project usage with either GradleExecutionContext or
associated Settings class.
Set of Setting classes are meant to be created upon configuration phase.
Therefore, they have to be easily serializable without heavy
payload. They also annotated for Input/Output checks.
^KT-43293
In K1, upper bound violated causes candidate to have lower applicability
due to constraint errors, in K2 however constraint errors has to be
reported explicitly
Don't add associate dependencies to test runtime classpath as it's managed by AGP
and might lead to duplicate dependencies and runtime problems.
KT-49877
Add dependencies from associated compilations conventionally
for Android, as it's done for all other multiplatform targets.
It used to work unintentionally before because of the configuration
name clash between test compilation and its default source set.
KT-35916
KT-49877
Add 'compilation' postfix to configuration names of compilations.
This is necessary to distinguish them from source set ones.
Without the change, default source sets of test compilations
and the test compilations themselves have the same name.
For instance, jvmTestImplementation was interpreted as
a configuration for a source set jvmTest and a compilation
with the same name. This leads to incorrect configuration
hierarchies and unexpected dependencies in them.
KT-35916
KT-49877
Previous implementation of `@ExportObjCClass` relied on the fact that
initialization of top-level fields was eager, i.e. happened during
Kotlin runtime initialization, when Kotlin code is accesses for the
first time.
With the new MM, initialization of top-level fields became lazy, it
happens when the particular file is accessed for the first time.
This commit fixes `@ExportObjCClass` with the new MM by making the
initialization of particular top-level fields eager.
^KT-53373 Fixed
Anton Lakotka