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
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.
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
Fake overrides are still created for java static with non-empty overriddenDescriptors
Add tests for inheriting visibility for java static members
Add test: check that java static declarations that shadow deprecated declarations should not be deprecated
Add test for corner case where "overriding" java static constant led to incorrect type in inheritor
Fix test data for existing tests
When checking for overloads in package, consider functions and top-level class constructors as possibly conflicting between each other. NB OverloadUtil uses containing package scope from module descriptor.
Change diagnostic message for CONFLICTING_OVERLOAD: it's misleading in case of fun vs constructor conflict.
Add custom multifile test for diagnostics in IDE (probably not the best; should preprocess file content if it's required to check highlighting in multiple files, not only in the first file).
Add test for KT-10765 Incremental compilation misses overload conflict between constructor and function ...
Yan Zhulanow