* Register project structure metadata providers globally, so included
builds can access it from the root build.
* Rework some dependency management logic so that it doesn't assume that
dependencies resolved to projects are safe to access – it is so only
if the project is in the same build; also, in dependency handling, use
proper keys which distinguish project with same ID in different
builds.
* Add a separate implementation of `MppDependencyMetadataExtractor` that
reads the project structure metadata from the mentioned global storage
(as we can't read it from artifacts – those are not yet build at the
project configuration phase) but when it comes to artifacts
processing, takes real artifacts rather than introspect the project
structure.
* Register the Kotlin/Native host-specific metadata artifact
configurations as consumable, so that a consumer from a different
build can properly resolve a dependency to such a configuration and
get the artifact.
Until now, there was a separate module foo-metadata that contained the
Kotlin metadata artifacts. The reasons for this were only historical,
namely the platform modules used to depend on the metadata module and
expect it to bring the common sources to the IDE.
Now we don't really need the -metadata module, and it's now more harm
from it than good, as users never need to specify it as a dependency.
We fix this by removing the -metadata module from the default publishing
layout and putting the -metadata artifact(-s) directly to the root
module.
Earlier, the matching was non-trivial and required the consumer to look
through all of the producer's targets to find the Kotlin variant given
the name of the configuration that Gradle chose during variant-aware
dependency resolution. This is not feasible in composite builds as we
can't look into a project model of an included build.
To fix this, simplify the matching of the Gradle configuration name and
the Kotlin variant name by just using a suffix for the published
configurations.
Namely, instead of names like `jvm-api`, use the original configuration
name `jvmApiElements` for Kotlin variant names. To avoid ambiguity with
Gradle configurations (which we might want to customize for publishing,
like by altering the attributes or the published artifacts compared to
the configuration exposed for inter-project dependencies), create
publishing configurations
While we already had the associateWith relationship
that established additional visibility between such
source sets as fooMain and fooTest, this
relationship was not used properly when requested
dependencies were built for source set visibility
inference in HMPP. Instead, an old workaround was
used that just added dependencies of commonMain to
commonTest.
Fix this by using the associateWith relationship in
the preparation logic of source sets visibiltiy.
ALso, make the artifact view used in source sets visibility inference
lenient, so that a host-specific module that has not yet been published
won't lead to fail in source sets visibility and will instead be
ingored.
Use it to check that only the value parameters that are explicitly
marked assignable are assigned.
Currently, the only parameters marked assignable are those for
default argument stubs.
The actual problem is a lack of plugin activation check in ParcelableUltraLightClassModifierExtension (see how it should be done in ParcelizeUltraLightClassModifierExtension). However, ParcelableUltraLightClassModifierExtension lays inside ADT sources, and it's impossible to make an fast&easy fix from our side. However, we control the compiler plugin on which the IDE support is based, so the check is added there.
There should be no troubles if the application with 'kotlin-android-extensions' includes an Android library with 'kotlin-parcelize' or vise-versa, as runtime libraries of both plugins are attached to the 'implementation' Gradle configuration since AGP 2.5.
Move collectionStubMethodLowering before jvmInlineClassPhase, and make
them interact properly.
Note that some issues still remain in inline class <-> special bridges
interaction.
KT-40187 KT-42469
This is a follow-up to b497f39c29. It
turns out that it didn't help because `IrFunction.returnType` throws
exception, and checking for `IrUninitializedType` in `IrType.render` was
already too late. Throw and catch specific exception instead.
Also add function name into the exception message for better diagnostics
elsewhere (can't compute the full FQ name because in cases like
KT-42020, the parent is also uninitialized).
This allows kotlin-native to generate code in debug mode.
LLVM requires debug attributes for this code and SYNTHETIC_OFFSET
makes kotlin-native generate dummy debug attributes.
Pavel Punegov