#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
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)
See the test and the issue for the clarification
After the change 7898922066
the expected type for "a" in expression "foo(a)" is A<E & B<*>>
But we have the original type A<E> and smart-casted enriched type A<B<*>>
(non of them is a subtype of A<E & B<*>>)
and fail in checkTypeInternal when checking types in during completion
^KT-35844 Fixed
Here we introduce ONLY_IMPLICIT_RECEIVER tower level
to support extension lambda calls on local variables,
and soften extension receiver checks to make such extensions visible & applicable.
Also here we try to map arguments twice for functional types
Nullability constraints should not be chosen when proper
argument constraints for variables in contravariant position present.
^KT-32106 Fixed
^KT-33166 Fixed
Force constraint system completer to always fix variable with unknown position.
This makes inferred type for in parameters less specific, but OI infers to
subtype in such cases, so NI won't infer to less specific types than before.
Current selection of completion mode for call is not always correct in case of full mode,
and sometimes too conservative in case of partial mode. Updated algorithm checks constraints
wrt position of type variables in return type and in other related constraints.
Full completion happens if proper constraint requirements are satisfied for variables.
Mikhail Glukhikh