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.
When calling a function whose parameter specifies a function builder
with a multi-statement closure argument, transform the closure into
a single expression via the function builder. Should the result
type checker, replace the closure body with the single expression.
- Add a precondition on `doesDeclRefApplyCurriedSelf` to expect
a member decl, and rename it to make the precondition explicit.
- Don't assume that not having a base type means this isn't a member
reference, as member references to static operators don't have base
types.
Resolves SR-10843.
Correct a regression related to use of partially applied initializers,
which should be rejected only if it happens in a delegation chain.
Resolves: [SR-10837](https://bugs.swift.org/browse/SR-10837)
Resolves: rdar://problem/51442825
Use this function to replace various places where the logic is
duplicated.
In addition, isolate the logic where subscripts are treated as having
curried self parameters to CalleeCandidateInfo, as their interface types
don't have a curried self, but get curried with self by
CalleeCandidateInfo. Ideally we'd fix this by having a subscript's
interface type be curried with self, but given that most of this CSDiag
logic should be going away, this may not be necessary.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
While computing a type of member via `getTypeOfMemberReference`
let's delay opening generic requirements associated with function
type until after self constraint has been created, that would give
a chance for contextual types to get propagated and make mismatch
originated in generic requirements much easier to diagnose.
Consider following example:
```swift
struct S<T> {}
extension S where T == Int {
func foo() {}
}
func test(_ s: S<String>) {
s.foo()
}
```
`foo` would get opened as `(S<$T>) -> () -> Void` and contextual `self`
type is going to be `S<String>`, so applying that before generic requirement
`$T == Int` would make sure that `$T` gets bound to a contextual
type of `String` and later fails requirement constraint `$T == Int`.
This is much easier to diagnose comparing to `$T` being bound to
`Int` right away due to same-type generic requirement and then
failing an attempt to convert `S<String>` to `S<Int>` while simplifying
self constraint.
Resolves: rdar://problem/46427500
Resolves: rdar://problem/34770265
