Add PropertyDescriptor.backingField/delegateField to store annotations
on the field directly in an otherwise almost empty descriptor instance,
instead of storing them with use-sites in the corresponding property
descriptor. Instead of AnnotationWithTarget, create AnnotationDescriptor
instances in AnnotationSplitter. Change DescriptorRenderer to render
annotations on "related" declarations when needed, with the explicit
use-site target if applicable.
Most changes in diagnostic test data are related to the fact that
annotations which are known to have an incompatible use-site to the
declaration they're applied at (such as `@param:`-annotation on a
function), are now not loaded at all. It's fine because the code is
erroneous, so it doesn't really matter how do we load annotations with
invalid targets (some of this logic is also changed freely in subsequent
commits). Some changes are also explained by the fact that for example
an annotation on the property which is only applicable to FIELD is now
rendered with an explicit use-site target `@field:`, regardless of
whether it did have that use-site target syntactically or not.
Basically, after this change there's no point in calling
Annotations.getUseSiteTargetedAnnotations/getAllAnnotations anymore
because it's easier and more intuitive to just use Annotations of the
corresponding descriptor -- the backing / delegate field (introduced in
this commit) or the extension receiver / setter parameter (related
behavior was fixed in previous commits). Usages of
use-site-target-related methods will be refactored out in subsequent
commits
For example, previously on an (incorrect) code like
@setparam:Ann
val x = 42
We added Ann to x's annotations. Not doing this seems more correct and
simplifies implementation a bit.
Test data is NOT changed in this commit because effective changes
somewhat depend on the changes in the subsequent commits. Affected tests
are at compiler/testData/diagnostics/tests/annotations/withUseSiteTarget
Make it possible to specify annotations of the setter parameter when
constructing the default setter via DescriptorFactory; pass the split
annotations in DescriptorResolver.resolvePropertySetterDescriptor
#KT-25500 Fixed
Consider an import from an inline function invocation. If it is
being called from another inline function, it should be defined
in a special way (e.g. `$$importsForInline$$.foo`) so that
the compiler knows where to load transitive dependencies from.
What's more, the declaration itself should be inside the inline
function wrapper.
Otherwise it should be defined in a regular way (e.g.
`$module$bar.foo` among other top-level imports).
By default the imports are loaded in the first form, and
transformed into the second one when needed. To check
whether this transformation the following predicate is
used: `inlineFunctionDepth == 0`.
At the moment the mentioned variable is increased upon
visiting an inline function declaration (`defineInlineFunction`),
and upon visiting an unknown (not visited before) inline function invocation.
It seems that instead the variable should be increased when processing
an existing inline function wrapper. At that point a new place to
put import definitions (`statementContextForInline`) is set.
Due to way JS code is generated (lambda's come before their call sites)
this issue seems to have been masked. Primary class constructors are a special
case - they come before any other declaration within. Hence a lambda
invocation inside a constructor leads to incorrect import definition.
* Generate the JARs with the same names as they are published.
Put the target name in the JAR name's appendix instead of classifier.
* Configure Maven publications eagerly to allow their editing by user.
* Take KotlinVariant's coordinates from the MavenPublication.
If the user changes Maven coordinates of the publication, this ensures
the parent component to have the updated information.
In Gradle < 4.7, there's no `ComponentWithCoordinates` interface, and we
need to make sure that none of our classes implementing this interface
are loaded with older Gradle versions.
Instead of that interface, we can rely on Gradle's metadata generation
heuristic that takes Maven coordinates for the variants from the
corresponding publications.
Note that this change brings an incompatibility: `Array<Foo>::class`
will be seen as `Foo::class` by the old deserializer. We consider this
OK because the compiler never had any logic that relied on reading class
literal arguments correctly (otherwise it wouldn't have worked because
it could only see `Array<*>::class` before this commit), and the support
of annotations on types in JVM reflection is only available in the
upcoming 1.3 release (KT-16795)
#KT-22069 Fixed
In new MPP, add source sets taking part in more than one compilation to
the tasks' `commonSourceSet` in order to pass them as -Xcommon-sources
Issue #KT-26515 Fixed
* Some of the usages of `kotlinSourceSets` should instead get all the
source set from the source set hierarchies, i.e. including the ones
transitively-participating in the compilation
After all MPP related changes, the `KotlinSourceSet` interface turns out
compatible with the old `KotlinSourceSet`, and, since there are external
usages of `KotlinSourceSet`, it is reasonable to expose the new
interface under the old FQ-name to fix those external usages.
Issue #KT-26498 Fixed
Alexander Udalov