See test with Java, we want preserve the invariant that if return type and
value parameter types are same in Kotlin, than we can use such return-value
as argument for that parameter
There are two different forms of types intestion:
1. Type parameters with multiple bounds
2. Smart casts
The problem was that when member scope of type intersection contained
effective duplicates and that lead to overload resolution ambiguity in
strange cases like `x.hashCode()`
For first type we do effectively the same thing as when building member
scope for class extending several interfaces: group all descriptors by
both-way-overridability relation and then choose most-specific in each
group.
For smart casts we do basically the same thing but with special
treatments:
1. From all descriptors that _equal_ to most specific we choose
the one that works without smartcast if possible (i.e. we choose first from candidates list)
2. If smart-cast value seems to be unstable we use only member scope
of receiver type + all descriptors from smart cast possible types
that has incompatible signature. If we'd include all of them and
choose one as more specific, and it would lead to false
SMART_CAST_IMPOSIBLE (see test unstableSmartCast.kt)
#KT-3996 Fixed
#KT-10315 Fixed
Given overridden descriptors D = d[i].
1. Find D*, subset of D:
returnType(d* from D*) <: returnType(d) for each d from D.
Always prefer var to val.
2. Prefer non-flexible return type to flexible.
Check for var/val overrides properly
(NB: this will report PROPERTY_TYPE_MISMATCH_ON_OVERRIDE
for all properties, not just overrides involving vars as it was before).
- Tests.
- No need for a separate diagnostic message regarding
return/property type conflict on override by delegation:
it is always a conflict of inherited signatures.
Overridden signatures should have compatible return types
(equal types for 'var').
Only relevant overrides should be taken into account.
Refactor inherited signatures check,
introduce a strategy interface for problem reporting.
It seems that all tests on that diagnostic were replaced in previous commits by
"repeated bound" and "no other bounds except a type parameter bound"
diagnostics
Before this change they could only negatively affect on result
Now they may force success result
Also refine overridavility condition for java fields:
two java fields having the same name are seen as overrides even
if they have different type
Zalim Bashorov