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.
Previously we returned a subscript member locator for an apply of a
subscript expr, which is incorrect because the callee is the function
returned from the subscript rather than the subscript itself.
The implicit TypeExprs for function builders were getting inconsistently set
types, which would sometimes be the metatype and sometimes not be the
metatype, leading to a crash in the new test code.
When we perform constraint generation while solving, capture the
type mappings we generate as part of the solver scope and solutions,
rolling them back and replaying them as necessary. Otherwise, we’ll
end up with uses of stale type variables, expression/parameter/type-loc
types set twice, etc.
Fixes rdar://problem/50390449 and rdar://problem/50150314.
A substantial amount of this patch goes towards trying to get at least
minimal diagnostics working, since of course I messed up the rule a few
times when implementing this.
rdar://50149837
Since we short-circuit in the function builder application when we
hit something we cannot translate, relying on that visitor to
detect 'return' statements (which disable the application) is bogus.
Use a separate, earlier visitor to find 'return' statements consistently.
Fixes rdar://problem/50266341.
Use the opened type from the callee declaration to open up references to
generic function builders that contain type parameters. This allows general
use of generic function builders.
If a function builder contains a buildIf function, then "if" statements
will be supported by passing an optional of the "then" branch.
"if" statements with an "else" statement are unsupported at present.
