Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
After introducing sourcesElements for Multiplatform projects the task
was not registered. As result of an assumption that Java Gradle Plugin
is taking care of sources publication. But in fact some users can
still rely on Kotlin's `kotlinSourceJar` task instead of JGP's
`sourcesJar`. This look inconsistent and is a matter of a different
issue: KT-54207
^KT-36943
Now when MPP library is published it will contain "sourcesElements"
variant for each target and one for common code.
Sources variants are published under gradle attributes that were
borrowed from Java Gradle Plugin for consistency reasons.
This makes it compatible with JVM tooling that rely on these attributes.
^KT-36943 Verification Pending
when they are grouped by flavor.
In such case a different implementation of SoftwareComponents is used
And originally only KotlinComponents were covered.
Replace it instead with dedicated property [usageScope].
Gradle no longer supports `Usage` and KGP used it only for mapping
dependencies to appropriate maven scopes.
write$Self in K1 is created only on JVM, so we need this check to avoid
creating IR function without original descriptor — it will lead to various
bugs in JS and Native, such as superclass properties missing from output
when super.writeSelf is not found in descriptor.
Fixes #KT-55180
Review: https://jetbrains.team/p/kt/reviews/7652
Put this change into a separate commit because:
1. The change is boring and clutters the diff of the first commit
2. The first commits is already too big
Review: https://jetbrains.team/p/kt/reviews/7652
It's not only unused, this dependency is conceptually wrong because
:compiler:frontend is K1 compiler but :analysis:analysis-api supposed to
be frontend independent
When serializing metadata for local delegated properties, we need to
find a valid container class where to put it, and where kotlin-reflect
will be able to find that metadata at runtime. Taking just the closest
class lexically doesn't work, because in the attached test, it is a
class for a lambda which does not have metadata and thus does not have a
way to store any extra information.
So, in 1663619606 we started to look for the closest "non-synthetic"
class to store this metadata. But apparently it was missed that script
is a valid container class. In the test, this meant that no
non-synthetic container classes were found to store the metadata, so we
falled back to using the closest class anyway (see `?: this` in
`rememberLocalProperty`), which turned out to be the lambda.
After this change, metadata for local delegated property in a lambda
will be stored in the script class, just like it's stored in the file
class in the non-script case.
#KT-55065 Fixed
Now annotations are resolved with following algorithm:
1. On COMPILER_REQUIRED_ANNOTATIONS we resolve all annotations
and store results if this is compiler annotation, plugin annotation,
or annotation with meta-annotation (meta annotations are checked
recursively with designated resolution if needed)
2. On TYPES stage we resolve all those annotations once again and if
some annotation changes resolution then we keep type from p.1 and
report error on this annotation, so user should disambiguate it
Ambiguity may occur because of nested annotations with same name as
plugin annotations:
```
annotation class SomeAnnotation // (1) plugin annotation
open class Base {
annotation class SomeAnnotation // (2)
}
class Derived : Base() {
@SomeAnnotation // <-----------------
class Inner
}
```
At COMPILER_REQUIRED_ANNOTATIONS annotation call will be resolved to (1)
because at this stage supertypes are not resolved yet, and we consider
only importing scopes. At the TYPES stage we will find correct
annotation from supertype
Sebastian Sellmair