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
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
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
Before this commit, class super-type could be sealed only in the case
it's the class we are inside or in the same file with.
However, it's quite possible for the expect sealed class
to be implemented by typealias.
So in this commit we allow class super-type to be sealed
if it's typealias expansion we are inside.
We might want to add 'init' blocks later, so now, for the sake of
binary compatibility with 1.3-RC binaries, we have to generate these
'constructor' calls.
Note that in some tests inline class boxing is no longer redundant,
because resulting value is passed to 'constructor' as an argument.
get rid of descriptors in Bridge and Enum lowerings
Replace property accessors function type with IrSimpleFunction because they couldn't be constructors
get rid of descriptors in Callable reference lowering
refactored descriptor factory and inner class lowering
Add isReified property to IrTypeParameter declaration
keep getting rid of descriptors
Get rid of descriptors in Shared Variable Manager
LocalDeclarationLowering also uses no descriptors
Fix psi2ir
Fix nested classes names
Fix outer reference in inner classes
Fix name generator
get rid of descriptors in coroutines - something is working
Fix name generator
Fix unbound symbols in JVM BE
Rename DeclarationFactory members
These three methods are conflicting with existing extensions,
thus the behavior might be changed when switching to JDK 11
Probably, it's worth revisiting our strategy here,
e.g. by blacklisting all new methods in
#KT-24974 Fixed
Suspend functions and callable references to suspend lambdas are already
supported.
Support callSuspendBy of suspend function of big arity.
#KT-24854: Fixed
- Why we bother? Because this test tries to read @Metadata via
reflection, and in 1.3 @Metadata has @Since("1.3") annotation. Thus,
with version fixed to 1.2, this test fails with UNRESOLVED_REFERENCE
- Why it is correct? Because initially this directive was used to enable
'LanguageFeature.JvmPackageName' (we didn't have infrastructure for
enabling particulare feature at that moment). So, now we could change it
to the '!LANGUAGE:+JvmPackageName', but it is actually redundant,
because master is already >= 1.2
Alexander Udalov