Return the destination array instead of the destination storage array
wrapped in a new unsigned array. The difference should be
indistinguishable, however in JS, where inline classes are not inlined yet,
it had resulted in an extra wrapper.
Intention: obtain lambda argument for some parent call,
then get that call (for the lambda argument) and map
the argument to the parameter.
Before the fix, we were getting call for inner element,
not for the lambda argument and as a result, there were exceptions.
#KT-26873 Fixed
The traditional Gradle/Java model assumes several configurations, which
are now deprecated, which are both `canBeConsumed = true` and
`canBeResolved = true`.
* compile, testCompile, etc.
* runtime, testRuntime, etc.
* default
These configurations need to somehow resolve correctly to an appropriate
platform-specific artifact when they contain an MPP library or project
dependency.
However, simply marking them with the Kotlin platform type attribute
would put these configurations under considerations during Gradle
variant aware depdendency resolution of project dependencies, which
in order would lead to ambiguity (e.g. `compile` vs `runtime` vs
`testCompile` vs ... vs `apiElements`).
To deprioritize these configurations during dependency resolution, we
mark them with a special attribute with a unique value in each project.
Given that the values are different in different projects, Gradle will
not choose a configuration marked by this attribute.
But we still need 'project(path: '...', configuration: '...')`
dependencies to work, and so, instead of rejecting those different
values of the attribute, we say that all values are compatible, but
when an ambiguity arises, choose the configurations not marked by this
attribute, so effectively eliminating them from resolution.
Issue #KT-27111 Fixed
* To avoid unexpected effects from the Gradle instantiation mechanisms
for attribute values, use a safer String attribute type for the
KotlinPlatformType attribute
* Rename its entries to keep enum entries naming consistent
* Add resources processing to the K/N compilations
* Use a proper resources output path (composed from target + compilation
rather than just compilation name)
* Fix incorrect reassignment of the resources directory
When a new MPP is published without Gradle metadata, the project
dependencies should be replaced with specific module dependencies,
e.g. `sample-lib` with `sample-lib-jvm`, because a consumer won't be
able to resolve `sample-lib` in a variant-aware way.
The following parts of the publications are affected:
* root publication
* with Gradle metadata, it is published and references the
other publications using the `available-at` mechanism
* without metadata opt-in, it is not published
* Kotlin metadata variant
* with Gradle metadata, it is added as an additional variant to the
platform-specific publications to allow the IDE to discover it
* without metadata opt-in, it is added as a dependency to the platform-
specific modules (like in old MPP)
Dmitry Petrov