Type of '::foo' for a function foo in a class A should be KFunction0<Unit>, not
KFunction1<A, Unit>. Continue to report an error in this case, to be maybe
supported in the future
Do not call `isError()` on property's type right after creation of
PropertyGetterDescriptor because the property has no getter yet (it's created
but not yet stored to the property, that happens a bit later), and `isError()`
leads to computation of the delegate type, which for delegated properties
performs some complex resolution (see `VariableTypeResolver#process`) which
relies on the fact that the property already has a getter.
Since the purpose of the original change (883e2e4d) was to support a quick fix
which would add the type to a property in an expression like "val x get() =
...", check the type (or initializer) presence in the PSI instead, this is
safer and is still suitable for the quick fix.
Also fix arguments to "wrong getter type" diagnostic: previously something
useless like "expected Int, actual Int" was reported
#KT-11809 Fixed
Use the same component (NotFoundClasses) as in loading of compiled Kotlin
symbols.
Some tests were changed to avoid a diagnostic that is now reported when a
non-found class is encountered in a signature (e.g. staticMethod.1.java where
JDK seems to be not configured)
#KT-10493 Fixed
#KT-10820 Fixed
#KT-11368 Fixed
Load immutable flexible upper bound for 'Iterable<? super T>'
We load 'Collection<? super CharSequence>' as 'MutableCollection<in CharSequence>'
instead of 'MutableCollection<in CharSequence>..Collection<*>'
because it's obviously not typesafe to use any 'Collection<*>'
as argument for such type.
But there'se nothing bad with loading 'Iterable<? super CharSequence>'
as 'MutableIterable<*>..Collection<*>'. Same for other declarations that have
covariant mutable representation (currently Iterator, ListIterator).
Also there are useful use-cases when it's neccessary to use 'Iterable<*>'
as an argument for parameter with type 'Iterable<? super T>' (see matchers.kt test).
NB: Star-projections appear in examples because types like 'Collection<in CharSequence>'
with conflicting use-site projections are invalid in Kotlin, but they are valid in Java.
They do not work anyway by many reasons:
- 'org.jetbrains.annotations.*' are not TYPE_USE targeted
- raw type with annotated arguments is something very weird and should be
investigated
It helps to get rid of semantics duplicating and fixes known bugs
- SOE in OnlyAbstractMethodFinder.find
- type enhancement for SAM constructors
#KT-11287 Fixed
#KT-11322 Fixed
EA-77989 Fixed
Mostly it's about detecting loops in supertypes
Test data changes:
- Loops are being disconnected in Java classes too
- functions.kt: loops disconnection mechanism runs supertypes calculation,
so when we start check T it forces F' supertypes calculation, that ends
with CYCLIC_GENERIC_UPPER_BOUND reported on F
#KT-11287 In Progress
Yan Zhulanow