More specifically, it should be done *just before*
JvmPropertiesLowering, as walking the IR tree between them will result
in visiting the moved backing fields twice (once via the companion's
parent, once via the IrProperty).
Ideally, this group of 3 lowerings should be merged into 1 as they are
completely inseparable, but this is slightly harder to do properly.
#KT-42527 Fixed
`in x` is represented as `<subject expression> in x` in psi, so
generating the entire call and then replacing the argument with a read
of a temporary results in redundant regenerations of the subject.
#KT-42054 Fixed
#KT-42455 Fixed
Unlike signed integers, a larger unsigned type does not mean a lower
minimum value, so `x - 1` can overflow even if `x` is casted to a larger
type.
#KT-42186 Fixed
* 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.
Denis Zharkov