Error arises from the fact that type substitution operation isn't
consistent when applied to captured types.
E.g.:
```
substitution = { A => B }
substituteOrSelf(C<CapturedType(out A)_0>) -> C<CapturedType(out B)_1>
substituteOrSelf(C<CapturedType(out A)_0>) -> C<CapturedType(out B)_2>
C<CapturedType(out B)_1> <!:> C<CapturedType(out B)_2>
```
Relates to KT-53749
Before, we were wrapping the original constraint position into
ConeBuilderInferenceSubstitutionConstraintPosition twice during the
constraint substitution in builder inference.
It was causing problems with diagnostic reporting.
Remove TODOs about diagnostic reporting from FirBuilderInferenceSession.
Propagation of errors from the common system is now implemented
Diagnostic reporting in updateCalls isn't needed, since we
report errors after the system completion unlike K1
Relates to KT-53749
Pass constraint errors from the integration system into a candidate to
make sure it is reported later.
Related to KT-59426, KT-59437, KT-53749
#KT-55168 Submitted
This commit actually does two things:
- Adds Any scope to stub type
- Makes CheckDispatchReceiver treat stub types
as non-null for the unsafe call check to make such candidates viable
Related to KT-59369
Previously, because we didn't handle flexible types properly in
prepareCapturedType, projections inside flexible types would only be
captured during subtyping with captureStatus=FOR_SUBTYPING
which would lead to the constraint type being wrongly approximated
(see ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint).
Fixing the capturing produced two kinds of false positive diagnostics:
1. In ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint we would get two instances of cone types
that are structurally equal and containing the same captured type.
However, because we only skipped subtyping if the types were
referentially equal, we would get a contradiction here.
The fix was to use structural equality instead, which should be okay
as the captured type instances are the same.
2. Reified type variables were inferred to captured types because
flexible arrays with captured upper bounds
(Array<Foo>..Array<Captured(out Foo)>?) were not properly approximated.
#KT-62609 Fixed
This commit handles subtle situation when K1 represents flexible type
arguments as just T..T?, but K2 does it as T&Any..T?.
This can provoke a type like Captured(*)&Any..Captured(*)?,
and before this commit we couldn't find recursion inside Captured(*)&Any.
This could lead to explosions inside type system and inference errors
#KT-60581 Fixed
Before this commit, we allowed access to outer class type parameters
during resolve of type parameter bounds of a nested class.
In fact, outer type parameters are accessible in this situation
only if it's an inner class (or a local class).
This commit forbids such a usage. In the earlier fix of KT-57209
the same was done for regular type reference resolve.
#KT-61459 Fixed
#KT-61959 Fixed
This uses the same approach as
INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION where we use a visitor
to find a call to a symbol that contains the type variable in question.
#KT-56140 Fixed
Let ConeCompositeConflictResolver pass the results of the previous
resolver to the next one.
Otherwise, we get false positive conflicts when a set of candidates
can't be fully reduced by one resolver but could be resolved by the
subsequent application of multiple ones.
This change makes ConeCompositeConflictResolver order-dependent and
thus, ConeOverloadConflictResolver must be invoked last, because it
must work on a pre-filtered list.
Also, let ConeEquivalentCallConflictResolver use
FirStandardOverrideChecker instead of compareCallsByUsedArguments
because it's stricter.
This all fixes a false positive overload resolution ambiguity in common
metadata compilation that is caused by stdlib using the new KMP
format.
Now stdlib metadata is in the classpath, and so declarations from the
stdlib are returned from both MetadataSymbolProvider and
KlibBasedSymbolProvider.
This isn't a problem per se because duplicate candidates are filtered
out by ConeEquivalentCallConflictResolver (K1 works analogously), but
in the case of top-level functions with generic receivers like
Collection<T>.toTypedArray, the check failed because of the direct
comparison of receiver types.
#KT-60943 Fixed
The change in `FirPsiDiagnosticTestGenerated.Resolve#testCast`
only highlights the existing
problem that we don't assign a
valid type to `_`.
^KT-58906 Fixed
A new resolution diagnostic UnsuccessfulCallableReferenceAtom is
introduced that is used in EagerResolveOfCallableReferences.
No diagnostic is reported on unresolved calls with this diagnostic
because
#KT-59856
The error occurs when completing the
call for the outer synthetic call
`ACCEPT_SPECIFIC_TYPE`. The error
is saved into the CS of this outer
candidate, which leads to its
callable reference to be an error
reference, but since such calls are
not parts of the FIR tree, we never
collect such errors.
^Fixed KT-59233
When reporting INFERRED_TYPE_VARIABLE_INTO_EMPTY_INTERSECTION, search
for a call to a declaration with the type parameter that got inferred
into an empty intersection inside the expression.
#KT-56377 Fixed
Simon Ogorodnik