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
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.
Avoid name clashes in cases such as
inline class Login(val login: String)
inline class Password(val password: String)
fun validate(login: Login) { ... }
fun validate(password: Password) { ... }
The design is to use `suspend fun` instead of coercion, just as suspend
lambdas.
However, this syntax is not supported in the parser. But this is not a
problem, since the coercion lead to internal compiler error.
As a workaround everybody uses suspend lambdas.
#KT-24860: Fixed
The order of types enumeration has been changed recently:
previously it was collected at first from a child and then from
its parent, but now it's being collected in order of appearance
`CONFLICTING_JVM_DECLARATIONS` diagnostics are reported because we're
trying to generate functions from `Any` once for inline class and
once for data class
#KT-25760 Fixed
Previously, enum entries were treated by the data-flow subsystem similar
to other class/singletons. As a consequence, calls like
'Enum.ENTRY.property' had IdentifierInfo of 'property'.
However, specially for enum entries, descriptor of 'property' is one and
the same for all entries. It means that from the data-flow point of
view, 'Enum.ONE.property' and 'Enum.TWO.property' are *one and the same
data-flow values*.
It could obviously lead to some bogus smartcasts, so this commit
introduces separate IdentifierInfo.EnumEntry and uses it to build proper
qualified values.
^KT-20772 Fixed
The source of testdata change is following commit from the
intellij-community repo:
d2bfe3d14bfa48af585f1faddc9a0c37dc05e724
It changes how Java-resolution resolves constructors:
- before, *any* PsiMethod without type reference was treated as
constructor
- now, PsiMethod without type reference is treated as constructor
only if their *names also match*
In particular, in this test, 'void () {}', surprisingly, doesn't have a
type reference ('void' is parsed as PsiErrorElement:Identifier
expected), its name is '<unnamed>', and its visibility is
'package-private' (!)
Therefore, previously we thought that 'Nameless' has package-private
constructor and were reporting INVISIBLE_MEMBER.
Now we don't see any constructor so we add default constructor, which has
public-visibility -> error is gone.
Note that this change affects behavior only when "red" code is already
present in the project (for "green" code, assumption "method without type
reference is a constructor" is indeed correct).
Before this commit, expect super-class without constructors did not
provoke SUPERTYPE_NOT_INITIALIZED. However, it should, but only
if sub-type is normal class (not an expect one).
So #KT-24597 Fixed
Previously, packages `java.lang` and `kotlin.jvm` were imported on JVM
by default on the same rights, causing problems when the same classifier
existed both in `java.lang` and `kotlin.jvm`. Since the only known case
of such conflict were type aliases to JVM classes, the corresponding
classes (expansions of those type aliases) were manually excluded from
default imports. This made the code in DefaultImportProvider complicated
and resulted in multiple problems, regarding both correctness and
performance (see 82364ad3e5, a9f2f5c7d0, dd3dbda719).
This change adds a new concept, a "low priority import", and treats
`java.lang` as such. Since these imports are now separated from the rest
of default imports in LazyImportScope via secondaryClassImportResolver,
conflicts between classifiers are handled naturally: the one from
`kotlin.jvm` always wins (unless the one from `java.lang` is imported
explicitly, of course). This approach is simpler, safer and does not
require any memory to cache anything.
Skip ResolveToJava.kt test for javac-based resolve; it now fails because
of a weird issue which I didn't have time to investigate (this is OK
because it's a corner case of an experimental functionality)
The implementation is a bit obscure because this worked on JS since
Kotlin 1.0 and we should not break that; however, on JVM, a diagnostic
will be reported with old language/API version
#KT-25241 Fixed
See `checkStatementType`, we return `null` to reduce count of errors.
Also, note that named function which is used as last statement in lambda
doesn't coerce to Unit, this is a separate bug and will be addressed later,
see #KT-25383
#EA-121026 Fixed
When we resolve arguments of annotation, expected type of parameters can
be unknown. Therefore, if we'll try to load constants without expected type,
info about unsigndness will be lost. For primitives it worked because we
can differ type by its value
Denis Zharkov