* Set the local-to-project attribute on the compatibility metadata
variant's "elements" configuration; not setting this attribute could
lead to ambiguity because of diverging sets of non-matched attributes
* Don't create the `runtimeOnly` configuration for the Kotlin/Native
targets (or potentially other targets with no runtime dependencies),
as the K/N target configurator is not aware of the configuration and
would not set the configuration up properly
* Don't create the legacy `*Default` configurations, as they basically
duplicate the `*ApiElements` / `*RuntimeElements` configurations but
don't have all the right attributes, so they are reckoned compatible
with some consumers unnecessarily and pollute the dependency
resolution error reports.
Issue #KT-47506
There are several changes here but they all required for at least one test to pass.
- Implemented String class and several utility functions using built-in CharArray
- Added new constant memory segment to hold string literals and required funcs to work with them
- Added very crude mostly incorrect rudimentary ability to pass strings back to javascript
Implemented `test multiple cinterops with test source sets and compilations`
This test will assert source set dependencies
and shared native compilations.
^KT-47775
^KT-47053
^KT-47775 Verification Pending
This implementation will be lenient toward the common
*Test.dependsOn(*Main) mistake.
^KT-47053 Verification Pending
Support source sets that do not have a dedicated
shared native compilation. Also support additional visible source sets
coming from associate compilations.
Adapted existing `test KT-47641 commonizing c-interops does not depend on any source compilation`
to add a project dependency from a project with c-interops (p2)
to a project without any c-interops (p0)
This leads to compilation of project p0, since the
cinteropApiElements configuration was not created on p0
- KotlinNativeCompilation
Change how associate compilations are connected.
Instead of using the implementation configuration, it now uses
the `compileDependencyFiles` directly. This will keep the
implementation configuration from containing any main compilation's
output. Therefore this configuration can still be forwarded to the
cinterop tool.
- KotlinNativeTargetConfigurator.kt CInteropConfigurations.kt
Create special configurations for cinteropApiElements and
cinterop dependencies. This configuration is tries to resolve
only cinterop dependencies when such variants are offered by a project.
^KT-47641 Verification Pending
Ensure that the serialization plugin's artifact (and, possibly, some
other prioritized plugin artifacts) are put first to the -Xplugin=...
classpath passed to the compiler.
This fixes the conflict of the serialization plugin with some other
plugins altering the IR in unexpected ways.
Issue #KT-47921
This may happen when build itself is running on JDK9+ and toolchain
is set to <=JDK1.8. CompilerEnvironment gets 'tools.jar' from the
current Gradle Daemon JDK, but there was a check if exception should be
thrown that uses 'javaVersion' from toolchain provided JDK.
Additionally also fixed 'tools.jar' was not provided for
'KotlinCompileWithWorkers' task.
^KT-47940 Fixed
* Add a new single flag for enabling HMPP:
kotlin.mpp.hierarchicalStructureSupport
When this flag is enabled:
* The old HMPP flags gets enabled, too, for old consumers
* The commonizer gets enabled as well
* An internal flag is set to indicate that the old flags were set by
the plugin
* Add an internal flag that we should flip when HMPP becomes the
default: kotlin.internal.mpp.hierarchicalStructureByDefault
With this flag is enabled:
* All MPP projects will use the composite artifact and
compile metadata with the KLIB compiler
* The compatibility metadata artifact will be gone
* The new HMPP flag is enabled by default
* Add consistency checks for new VS old flags
Issue #KT-40245
This is a continuation of KT-46936. This commit removes stdlib-common
from platform-specific source sets of JS/Native targets, as well as
Android and 'jvm { withJava() }'
The tests are made on kotlin-ide side, see the KT-46936 for attached
commits.
^KT-46936
^KT-47695 Fixed
^KT-47604 Fixed
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
These compiler arguments enable features which are enabled by default in
the current Kotlin anyway.
The only exception is in :compiler:cli which uses an old language
version.
Abduqodiri Qurbonzoda