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.
We should never do that, because otherwise we can get unexpected result.
Example for input constraint: C(in String) <: T.
If we run usual subtyping algorithm, then we get 2 constraints:
C(in String) <: T and T <: String.
Of course such system has contradiction.
We prefer denotable types when we solve constraint system.
I.e. if for T we have not equality constraint with captured type we can approximate captured type to denotable type.
This is bad idea, but this is how it works in old inference.
Now we just save old behaviour.
Future plan: fix checks where we get unfinished resolved calls.
- report WRONG_NUMBER_OF_TYPE_ARGUMENTS
- make integral types work again: IntegerValueType is represented as {Int & Byte & Short & Long} in the constraint system
"Empty" is slightly confusing because although the scope has no declared
symbols, it is not empty: it has a parent scope which can contain
symbols and can have parents as well
ScopeTowerProcessors.kt contains a few code snippets
that look like `collectCandidates(...).filter { ... }.map { ... }`.
Filter argument is always side-effect free, so it is safe
to merge `filter` and `map` calls into one for-loop.
The change also makes sense, because modified functions are quite hot.
For example `NoExplicitReceiverScopeTowerProcessor.simpleProcess`
produces 11,392,768 ArrayList instances (~1.08% of all objects)
when compiling the compiler according to aprof at the moment of writing.
On my machine the change improves compilation speed of the compiler up to 5%.
Some IDE features relates onto that same descriptors will remain same
between resolve calls
Fix it to be true for TypeAliasConstructorDescriptor's
#KT-16265 fixed
Dmitry Petrov