In particular, this commit includes:
* Attempt to abstract access to FirSourceElement via FirModifier
* Add more visit functions to DeclarationCheckersDiagnosticComponent
* Add messages+factories for 4 modifier-related errors and warnings
* Introduce FirModifierChecker
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
Call checker and declaration checker are used in order to preserve backward compatibility.
Attempt to use classifier usage checker was not good enouth,
since not all errors found with it would actually be reported before.
For example types and constructor calls don't cause supertypes to resolve,
so missing supertypes would not lead to errors in case they are the only use of class name.
Updated tests failing due to missing Java dependencies in superclasses.
Disable annotation rendering in default type and descriptor renderers.
Preserve annotations in Android and Serialization plugins.
Update error texts in ide tests.
Nullability annotations in Java descriptors are rendered with context-dependent renderer.
#KT-20258 Fixed
Expression will be checked against expected type later.
Theoretically, this is not very good, but it aligns with the old
inference, plus it helps avoiding multiple type mismatch diagnostics.
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
If property accessor rendering is disabled in a test, render annotations
on accessors as use-site-targeted, as was done with
`@setparam:`-annotations. Otherwise they were lost
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
#KT-21696 Fixed
The problem is coming from the fact that `AnnotationTarget.VALUE_PARAMETER` is mapped to receiver parameter and to value parameter, but annotation with use-site target `receiver` can be used only on type reference of receiver parameter
In case the referred type is actually an enum that is not found in
dependencies due to a configuration problem, this usage could be valid.
So we can avoid reporting an error here, to reduce the number of
diagnostics.
Also do not report "default value of annotation parameter must be a
compile-time constant" in the same case for the same reason
From Kotlin's point of view, everything in annotation classes is
non-abstract. A class inheriting from an annotation has a non-abstract
fake override for each property of the annotation class constructor. But
because members of annotation classes themselves were considered as
abstract in the bridge-generating code (see
DescriptorBasedFunctionHandle.isAbstract), there was a situation where a
concrete fake override has only one declaration among overridden
descriptors and it was abstract. This situation is invalid (a concrete
fake override must have exactly one concrete super-declaration),
therefore an exception was thrown.
The fix is to avoid considering annotation class members abstract for
the purposes of bridge generation. It's reasonably safe because no
bridges should be ever generated for annotation subclasses anyway,
because annotations can only have members with simple return types
(final and non-generic).
Note that in KT-19928, the problem is reproducible because of an
incorrect "inexact analysis" in light classes where "Target" is resolved
to an annotation class kotlin.annotation.Target. This behavior of the
analysis in light classes seems to do no harm otherwise, so it's not a
goal of this commit to change anything in that regard
#KT-19928 Fixed
Mikhail Likholetov