#KT-36247 fixed
A lot of testdata changed because significanly less (error) descriptors
are created for unresolved types, so diagnostics became different.
Previously, resolved call is expected to have SAM converted argument map
if SamConversionPerArgument is enabled. However, if SAM argument is
followed by vararg parameter and an array _without_ a spread operator is
passed, New Inference left a type mismatch error on a resolved call, which
made that resolved candidate filtered out. Instead, another resolution
result wihtout SAM converted arugment map will be provided.
All other logics, such as adding SAM conversion type op and lowering SAM
conversion and/or call references, are already there for resolved calls
without SAM converted argument map. This change just relaxes the bailout
condition so that array passed to vararg after SAM argument can be
handled in JVM IR.
New resolution applicability is needed in cases when error is found,
but candidate still should be selected. Currently there are two cases,
when this behaviour is required:
- unstable smartcast (choose candidate with non-nullable parameter)
- unknown lambda parameter type (against non-functional expected type)
KT-36264
There are several issues with unsafe desugaring for convention calls.
Proper fix is not implemented here (see design proposal KT-30872).
This commit only applies the old logic in the new inference.
^KT-30695 Fixed
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
Callable reference is "adapted" if it requires some adaptation to an
expected function type - e.g., when a reference to
```
fun foo(vararg xs: Int): Int
```
is used where `(Int, Int, Int) -> Int` is expected.
For such callable references we generate the following IR (in
pseudo-Kotlin):
```
{
fun foo'(p0: Int, p1: Int, p2: Int): Int {
return [| foo(p0, p1, p2) |]
}
::foo'
}
```
where `[| foo(p0, p1, p2) |]` is calling function `foo` with arguments
`p0`, `p1`, and `p2`, as they were mapped by callable reference
resolution.
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
In case of null qualifier, we should not look into any static scope
NB: factory::createCallableProcessor returns NoExplicitReceiver processor
in case of null-receiver, that makes resolving the call in the test as
`property(::key)` that matches to the property itself, thus leading to
overload resolution ambiguity
^KT-35887 Fixed
It partially reverts 7898922066
because it's not obvious that it's a safe operation
for invariant/contravariant types.
Also, there's a necessary fix in prepareReceiverRegardingCaptureTypes
to make types order stable
Otherwise test bareTypesWithStarProjections becomes flaky.
Also, the changes in bareTypesWithStarProjections.kt are also expected
because the type of the expression `coneSymbol` after the second "if" is
FirVariableSymbol<*> & FirPropertySymbol & AbstractFirBasedSymbol<*>
thus we fix D in the call `coneSymbol.phasedFir()` to FirVariableSymbol<*>
because it's the first type in the list
(see the next line after the last changed in AbstractTypeChecker)
Pavel Kirpichenkov