Commit Graph

12 Commits

Author SHA1 Message Date
Alexander Udalov 4692247897 Do not check backing field presence in AnnotationSplitter
This code can be invoked early, during body resolution and before the
fact that a property has backing field (which is only known for certain
after body resolution, because an implicit 'field' identifier may be
used). Since split annotations are cached until the end of the program,
they may end up on incorrect elements in the bytecode (or disappear
completely) as in KT-29507 or KT-28182.

Because the FIELD target has the lowest priority among implicit
annotation targets (see TARGET_PRIORITIES), it's safe to always assume
that FIELD is a valid target when splitting annotations. This only
changes the way annotations are split in case of incorrect code, as
changes in test data show.

 #KT-28182 Fixed
 #KT-29507 Fixed
2019-02-15 17:53:27 +01:00
Alexander Udalov f9b9b6908a Remove use-site targeted annotations from LazyAnnotations
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:"
2018-09-06 19:13:15 +03:00
Alexander Udalov fc87043cb3 Merge use-site targeted annotations into corresponding Annotations
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
2018-09-06 19:13:11 +03:00
Valentin Kipyatkov ec51076355 DescriptorRenderer to render annotations for all types + separate option to render annotation arguments + use it in IdeDescriptorRenderers 2016-10-11 23:38:54 +03:00
Alexey Tsvetkov dc27363452 Remove @annotation from test data 2015-10-19 20:45:01 +03:00
Alexander Udalov ec1b4776fe Deprecate PropertyMetadata, use KProperty<*> for delegated properties instead 2015-10-14 20:45:25 +03:00
Yan Zhulanow dc8e796e49 getValue()/setValue() should be marked with 'operator' 2015-10-14 01:29:09 +03:00
Yan Zhulanow 1f2b4e20fe Replace get() and set() to getValue() and setValue() (property delegates) 2015-10-09 22:49:16 +03:00
Denis Zharkov 4850fd10f0 Regenerate test data containing rendered descriptors
Introduced '@' after each annotation
2015-09-18 10:14:39 +03:00
Michael Nedzelsky bc5c9065d2 fix tests in org.jetbrains.kotlin.checkers 2015-09-08 02:04:32 +03:00
Yan Zhulanow 2ce9903356 Fix tests 2015-08-31 15:33:13 +03:00
Yan Zhulanow b38b7071b7 Targeted annotation diagnostic tests 2015-08-31 15:32:53 +03:00