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
In 1.3, due to changes in language, testdata for some tests can be
different from 1.2
We want to simlultaneously test both versions, so instead of fixing
language version in such tests, we split them into two: one with fixed
1.2, another with fixed 1.3
Note that this is not relevant for LOCAL/INHERITED visibilities:
- for LOCAL visibility it's impossible to have a qualifier
- INHERITED is an intermediate visibility, we enhance it later
(see resolveUnknownVisibilityForMember)
#KT-20356 Fixed
If a type alias is used to reference an object (companion object) as a
qualifier, record FakeCallableDescriptorForTypeAliasObject in
REFERENCE_TARGET. This tells IDE that type alias was used in the file,
thus, if it's imported, such import isn't redundant.
REFERENCE_TARGET is used mostly by IDE and by ClassifierUsageChecker,
which we also have to update to handle qualifiers with
FakeCallableDescriptorForTypeAliasObject in REFERENCE_TARGET.
Rewrite some parts of ClassifierUsageChecker for cleaner interaction.
#KT-21863 Fixed Target versions 1.2.40
Hack: callee expression for when with subject variable is the subject
variable declaration. This solves the problem that all sub-calls in the
expression are implicitly considered to have a single common lexical
scope (and 'when (val x = ...)' introduces a new lexical scope, which
contains 'x').
'Subject.Error' is redundant.
'Subject.None' can be an object.
'Subject#dataFlowValue' can be a lateinit property.
TODO: fix
- parsing local extension properties in 'when' subject
- parsing destructuring declarations in 'when' subject
- non-completed calls in nested 'when' with subject variable
- non-completed calls for subject variable in 'in' pattern
During subtyping/incorporation we transform types (e.g. changing nullability,
form of the type) and, basically, we're doing this to some FIXPOINT.
It's important that we use `KotlinType.hashCode()` to compare types, but
for error types hashCode is a hashCode of its supertype and, for example,
`makeNullableAsSpecified` method recreate type every time. So, we continue
to generate new constraints and we'll never stop incorporation algorithm
Supported:
- conversion in resolution parts. Also sam-with-receiver is supported automatically
- separate flag for kotlin function with java SAM as parameters
TODO:
- fix overload conflict error when function type is the same byte origin types is ordered
- consider case when parameter type is T, T <:> Runnable
- support vararg of Runnable
[NI] Turn off synthetic scope with SAM adapter functions if NI enabled
Such test has no ense in NI because NI it is LV = 1.4 and we cannot
repeat behaviour in 1.3 anyway, so I propose not even support old cases.
Also priority of LANGUAGE directive should be more then key enabled on
all tests -- also fixed.
Mikhail Zarechenskiy