1. Substitution variance (sv) is a substitution composition of type alias argument variance (av)
and corresponding expanding type argument variance (ev):
sv =
| av == ev -> av
| av == INVARIANT -> ev
| ev == INVARIANT -> av
| else -> (variance conflict error; av)
2. Resulting variance (rv) is a type argument composition of sv and type parameter variance (pv):
rv =
| sv == tv => INVARIANT
| sv == INVARIANT => INVARIANT
| tv == INVARIANT => sv
| else -> (variance conflict error; sv)
When resolving arguments on inner classifier, one can omit the arguments
for outer class 'Outer' if they are present implicitly in the scope:
- One of the supertypes of current class is Outer
- One of the outer classes or one of their supertypes is Outer
Relevant arguments are obtained from the first type found by
the algorithm above
Note that before this commit implicit arguments were only been searched
in containing classes
#KT-11123 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
Instead of erasing descriptors with conflicting substitution,
use invariant CapturedType(<projection>) as replacement for type parameter
within default member scope.
After substitution leave such types 'as is' everywhere except return types,
use common approximation for them.
#KT-9294 In Progress
#KT-5411 Fixed
#KT-8647 Fixed
#KT-9462 Fixed
#KT-9893 Fixed
#KT-7581 Fixed
#KT-7296 In Progress
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
If there's only one erroneous bound (vast majority of cases), report it on the
bound; otherwise (to avoid reporting it several times) report on the type
parameter declaration
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
Dmitry Petrov