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(*).
I'm not sure in this commit, but it fix some test -> let it be for now.
And yes, now I do not know correct way for callable reference resolution,
so for now it is just proposals.
If expected type for callable reference argument isn't callable type
then make such candidate unsuccessful.
Sometimes expected type is just `T`, where `T` is type variable.
To support such case we take all supertypes and check them instead.
Priority of variables and function should be the same.
Because of this we create new CompositeSimpleScopeTowerProcessor,
which merge candidates for properties and function into one candidate group
When completing calls, update return types for functional descriptors
for lambdas using type inference results.
Add toString to some Call subclasses (for debugging purposes).
Given a lambda result type R_L with constraint R_L <: T,
for each constituent type variable V in T with variance matching
approximation direction for V, consider a dependency edge V -> R
(lambda-result-dependency).
E.g., given a constraint:
R <: Out<V>
where V is approximated down (to sub-type).
After R is fixed, we obtain constraint
Out<T> <: Out<V>
which is incorporated as
T <: V
which is a relevant constraint for V.
1. Value arguments for the resolved call are indexed with resulting
descriptor value parameters (which can be substituted).
2. Simple argument can be a single vararg element if the corresponding
value parameter is a vararg parameter.
3. Resulting descriptor should be approximated to super-type.
This doesn't affect type inference, but the JVM BE expects types with
proper classifiers.
Also do not store type with captured type inside possible types.
It is hack for now, but without it captured types can flow to
resolution and exception will be thrown.
Dmitry Petrov