Note that this isn't fully correct, consider the following situation:
S : T, T : Any?
=> CS(S, T) = T, but for now it will be T?, which is reliable but not so specific as just T
The main change here is the following: before callable reference
resolution starts directly after choosing candidate. Since now we
start resolution before call completion.
Now there is 3 kind of KotlinCallDiagnostic:
- ResolutionDiagnostic
- ConstraintSystemCallDiagnostic
- other common diagnostic
Also SpecialResolutionParts were merged into other ResolutionParts
Also here argument resolution was divided to two parts:
for SimpleCallArguments and for PostponableCallArguments.
Call Resolution for SimpleCallArguments also used for CheckReceivers
and lambda result arguments checks
If we has Inv<T> <: Inv<Captured(in Foo)> then we should get:
- T <: Captured(in Foo)
- Captured(in Foo) <: T
Before this commit we got: T <: Foo instead first constraint.
It is important for provideDelegate resolution, because if scope has
provideDelegate with wrong receiver we shouldn't resolve to it and
report any errors.
Compute common supertype (regardless of whether the given set of
lower bounds contains number types, intersection types, or whatever).
If the result type S is a possibly nullable intersection X1 & ... & Xn,
N = {Xi | Xi is a primitive number type},
R = {Xi | Xi is not a primitive number type},
M = default primitive number type for {Nj},
then adjusted type T* = M & R1 & ... Rm with the same nullability as S.
NB: IntegerValueType(_) = Int & Byte & Short & Long
For cases like Enum<Captured(*)> where Captured(*) has supertype
Enum<Captured(*)> we get SO in TypeApproximator.
To prevent this argument depth was introduced.
If for type variable we have upper and lower bounds, then sometimes
our approximation before fixation give us incorrect result for type
variable and we should chose other bound as result.
Example: Int & Byte <: T <: Byte. If we run approximation for lower
bound we get Int as result and it isn't subtype of Byte.
Introduce a fresh type variable for lambda return type.
We can't set expected lambda return type to 'Any?', because we can't
infer the actual type from return expressions in lambda in that case.
Sometimes we have something like if (a is Foo<*>) a.bar()
where bar declared: fun <T> Foo<T>.bar().
For such case we should create receiver with possible types Capture(*).
Stanislav Erokhin