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
This commit is a hotfix rather then proper solution.
The source of the issue is that currently type variable fixation result
may change due to fixation order alteration for variables with the same priority.
For instance, having variables V1, V2, and proper types Type1, Type2, such that:
V1 <: Type1
V1 <: V2
Type2 <: V2
both variables will be fixed either to Type1, if V1 will be fixed first,
or to Type2 otherwise.
Since this limitation cannot be easily overcome, the taken approach is to remove
incedental constraint added after 2d5a0546 by restricting nullability constraint check
to `Nothing?` constraints only, thus postponing problematic variable fixation.
To clearify, additional constraint is correct and should cause no harm (in ideal world),
but currently its presence changes fixation order.
So without the restriction the previously used constraint from fixed outer variable
is no longer available by the time problematic variable type is being selected.
^KT-37043 Fixed
Full completion should not be done if lower `Nothing`
is the only proper constraint when constraint with ILT type is present.
ILT will be selected as a resulting type and transformed into `Int`
without attention to possible restrictions from outer calls.
#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
Type parameters can't be specified explicitly for special constructions.
Reporting this error does not help fixing the cause of it and needlessly
reveals implementation details.
^KT-36342 Fixed
Also use updated diagnostic pattern in TreesCompareTest.
In rare cases diagnostic was cut too early on !> characters,
that were a part of diagnostic parameter:
<!DIAGNOSTIC("Type<DefinitelyNotNullTypeArgument!!>")!>
Before fix only one level of type arguments was used to determine variance of type variable to find out direction requirements.
This incorrect in general case, because outer variance affects subtyping deductions, for example:
Inv<Out<A>> <: Inv<Out<B>> => A <: B; B <: A, despite A and B are in covariant position if only one level is considered
^KT-36233 Fixed
Unknown lambda parameter should not change resolve.
So the new diagnostic should not have error status; othrewise candidates with lower priority but more specific expected type may be chosen.
KT-34335 Fixed
See also KT-36264
Consider lower `Nothing` constraint non-proper only if there is a dependant not analyzed postponed atom.
Early completion to `Nothing` provides data flow info for smart casts.
KT-35668 Fixed
Coersion to Unit from error type leads to misleading type mismatches:
"expected <expected lambda return type> found Unit", despite no user-provided Unit / empty lambda.
These diagnostics were collected, but not reported before, and that had been disguising the issue for a while.
KT-34729 Fixed
Fix completion of anonymous functions with expression body without expected type.
Premature completion led to losing type info from outer calls.
Also report type mismatches on empty lambda expressions.
KT-34729 In progress
An uninferred parameter stub may leak through calculation of CST(Inv<Uninferred Stub>, Nothing) into a result type.
A stub type in the result type means a type error. So we can afford recalculating
CST with stub-containing types filtered out, since its an error anyway.
This prevents stub types leakages and helps with reporting type error diagnostics.
KT-35914 Fixed
KT-35943 Fixed
Mikhail Zarechenskiy