- Add marker for the experimental type inference features
- Add annotation that will control builder-like inference
- Require that annotation on corresponding parameters and extensions
- Allow to use builder inference without suspendability
Changes in tests and refactorings (rename mainly) are going to be
introduced in further commits
They are a kind of a hack applied in light-classes and it'd be nice
to prevent them being used in irrelevant contexts
kotlin-serialization-compiler module should not depend on idea,
thus we can't use annotations directly there.
So, we copy-paste them and add a test on names consistency
Otherwise, whether LazyLightClassMemberMatchingError happens
or other type of errors because serialization plugin expects
full resolution in the correct module
Currently, only @Serializable annotation leads to exceptions,
but just in case we consider both of them as potentially problematic
#KT-26895 Fixed
Otherwise we're not trying to load annotations on the parameter of the
property setter in MemberDeserializer.loadProperty.
Note that after this commit, we could now also assume that if
getter/setter is default, it has no annotations, and thus use
Annotations.EMPTY for default getter/setter in loadProperty. However,
this would cause reflection to work incorrectly on classes compiled by
an older Kotlin compiler, so we'll still try to load annotations on
default accessors for an indefinite time.
#KT-25499 Fixed
<IMPL_SUFFIX> for method is a method signature hash,
if method value parameter types contain inline class types,
otherwise 'impl'.
Constructor methods are named as 'constructor-<IMPL_SUFFIX>'.
Synthesized 'box' and 'unbox' methods are named as
'<METHOD_NAME>-<IMPL_SUFFIX>'.
Erased implementations of overriding and non-overriding methods
are named as '<METHOD_NAME>-<IMPL_SUFFIX>'.
Fully specialized implementation of 'equals' will have a special suffix.
Minimize AnnotationsImpl to leave it usable in simple scenarios where
there's no use-site targeted annotations, and use TargetedAnnotations in
the only place in the frontend (AnnotationResolverImpl) where use-sites
were needed.
Also, delete kdoc on Annotations.isEmpty to prevent readers from putting
too much thought into how it works. With the exception of a few places
in the frontend where use-site targeted annotations are still accessed
via the Annotations object, it's now an implementation detail and users
(such as backends, IDE) should not care about them at all, and instead
should just deal with the correct element when processing annotations
After this commit, it's overridden only in AnnotationsImpl and
CompositeAnnotations.
Note that although FilteredAnnotations did have a non-trivial
implementation, that class was only used in circumstances where
annotations with use-site targets could not be of any use, so it's safe
to return empty list there now. One could argue that the new semantics
makes more sense: filter "standard" annotations, but don't touch those
with use-site targets because they are not applied to this element
directly, thus should likely not be affected by the filtering
LazyAnnotations are only used for classes and files, and in the latter
case it will now contain file annotations as normal annotations, without
the target "file:"
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
Mikhail Zarechenskiy