In cases when all of the fixed solutions have only one problem in
common - different overloads of a certain operator, let's
produce a tailored diagnostic and suggest matching partial
overloads along side diagnostic notes which point to each choice.
If expression is incorrect it most likely wouldn't be able to satisfy
`Equatable` or other requirements of `~=` operator overloads, but
at the same time the main problem is related to `case` expression
itself so let's not diagnose missing conformances.
This removes all calls to typesSatisfyConstraint() except for the
isConvertibleTo() check at the beginning, in the process making the
analysis a little bit more accurate.
In order to do this we need it to take a ConstraintLocator argument so
we can tell which component we want the callee for. To make it clear
that we're looking for a callee at the anchor, also rename the member
to getAnchormostCalleeLocator.
We've fixed a number of bugs recently where callers did not expect
to get a null Type out of subst(). This occurs particularly often
in SourceKit, where the input AST is often invalid and the types
resulting from substitution are mostly used for display.
Let's fix all these potential problems in one fell swoop by changing
subst() to always return a Type, possibly one containing ErrorTypes.
Only a couple of places depended on the old behavior, and they were
easy enough to change from checking for a null Type to checking if
the result responds with true to hasError().
Also while we're at it, simplify a few call sites of subst().
There were a few places where we wanted fast testing to see whether a
particular type variable is currently of interest. Instead of building
local hash tables in those places, keep type variables in a SetVector
for efficient testing.
When we transform each expression or statement in a function builder,
introduce a one-way constraint so that type information does not flow
backwards from the context into that statement or expression. This
more closely mimics the behavior of normal code, where type inference
is per-statement, flowing from top to bottom.
This also allows us to isolate different expressions and statements
within a closure that's passed into a function builder parameter,
reducing the search space and (hopefully) improving compile times for
large function builder closures.
For now, put this functionality behind the compiler flag
`-enable-function-builder-one-way-constraints` for testing purposes;
we still have both optimization and correctness work to do to turn
this on by default.
Functions like `isRawRepresentable*` and `conformsToKnownProtocol`
have to be be shared between CSDiag and new diagnostics framework
until relevant code is removed from the former.
Currently, because argument info has been collected based solely
on anchor, it would be possible to overwrite labels for expressions
like `foo[0](x)` since `ApplyExpr` uses its function expression as
a key for argument information cache, which leads to errors while
attempting optimizations based on that information.
Simplify the interface to gatherConstraints() by performing the
uniquing within the function itself and returning only the resulting
(uniqued) vector of constraints.
1. If this is a special name avoid printing it because
printing kind is sufficient;
2. If all of the labels match, print a full name;
3. If labels in different choices are different, it means
that we can only print a base name.
For multiple solutions with fixes for the same call, replace
`ambiguous reference` diagnostic with the one that explicitly
mentions that there are no exact matches, and provide partially
matched candidates as notes.
Diagnose situation when a single "tuple" parameter is given N arguments e.g.
```swift
func foo<T>(_ x: (T, Bool)) {}
foo(1, false) // foo exptects a single argument of tuple type `(1, false)`
```
This calculates a result directly from the function's result type
instead of checking a bit that was previously set by the type
checker. Also, always returns true for constructors to simplify
some callers.
