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
For cases like if (..) ::foo else ::bar we didn't write stub resolved
calls for ::foo before call completion. Because of this, and strange
code in if we get null inside type info.
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.
If variable is generic call, then we should complete inference only
after invoke resolution. It means that explicit receiver for invoke
should be SubKotlinCallArgument.
But, if this property has no generics,
for example local property, then this property can have smartcast and
such call has no type arguments -> no completion required.
For such call we should store information about smart casts.
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.
Mikhail Zarechenskiy