Introduce seven stages:
1) Analyze postponed arguments with fixed parameter types
2) Collect parameter types from constraints and lambda parameters' declaration
3) Fix not postponed variables for parameter types of all postponed arguments
4) Create atoms with revised expected types if needed
5) Analyze the first ready postponed argument and rerun stages if it has been analyzed
6) Force fixation remaining type variables: fix if possible or report not enough information
7) Force analysis remaining not analyzed postponed arguments and rerun stages if there are
^KT-37952 Fixed
^KT-32156 Fixed
^KT-37249 Fixed
^KT-37341 Fixed
Replace it with a dependency on 'descriptors'.
Move the existing marker interface ContractProvider to 'descriptors',
and create a new marker interface DeserializedDescriptor.
Also move version string regex there and rename the class to
RequireKotlinConstants. This allows to get rid of dependency of
'serialization' on 'frontend'.
The new inference uses inferred intersection types normally, unlike the old inference.
However, intersection types in public declarations are approximated to supertype, which
potentially may give a less presice type, then it would be with the OI.
For non-related T1, T2 the NI approximates {T1 & T2} to Any in public declarations,
and if the OI was inferring T1 instead of the intersection type, it may lead to
less precise declaration type and related errors.
The solution is to remember an alternative for an intersection type when present.
Before approximation the alternative replaces the intersection type.
^KT-36249 Fixed
While we have an overload resolution algorithm working for O(n^2),
call resolution for the single particular call may work more then just
a second.
Thus, we need to call ProgressManager.checkCanceled() with more granularity
^KT-35135 Fixed
See 62a55b7b00
Previously, it was working for O(n^2)
Now, we first group it by jvm descriptor,
then for each groups of size g_i finding the most specific for O(g_i^2)
It should help for the cases when we have a lot of overloads with
different JVM descriptors (modulo return type)
NB: Having the same JVM descriptors is rather rare, because
in Java one cannot generate such a class.
Looks like it's only possible for Scala or some other JVM languages (KT-17560)
It should help a lot for KT-35135
Mikhail Zarechenskiy