Enable solver to transitively infer bindings through argument conversion
constraints. That helps to infer bindings for (generic) parameters
from their arguments e.g.
```swift
func foo<T: ExpressibleByStringLiteral>(_: String, _: T) -> T {
fatalError()
}
func bar(_: Any?) {}
func test() {
bar(foo("", ""))
}
```
In this case `T` can currently only be inferred as `Any?`
(based on parameter type of `bar`) although a complete
set of bindings for that type variable includes `String`
as well, which comes from use of `T` in argument position.
Resolves: rdar://problem/56212087
Just like in cases where both sides are dependent member types
with resolved base that can't be simplified to a concrete type
let's ignore this mismatch and mark affected type variable as a hole
because something else has to be fixed already for this to happen.
When there is a conversion from e.g. `(A) -> Void` to `(B) -> Void`
matching between `A` and `B` is going to have a special locator which
doesn't end in `TupleElement`, so `repairFailures` has to account
for that and fix it just like regular argument mismatch.
Resolves: rdar://problem/59066040
Prioritize type mismatches over conformance failures when stdlib
types are involved because it wouldn't be appropriate to suggest
to add such a conformance, so the problem is most likely related
to something else e.g. other overload choice has a better fix.
Consider following example:
```swift
struct S {
init(_: Double) {}
init<T: BinaryInteger>(_: T) {}
}
_ = S(Double("0"))
```
In cases like that it's better to prefer failable initializer
which takes a `String` and returns `Double?` and diagnose a
problem related to missing optional unwrap instead of missing
conformances related to a `String` argument of other `Double`
initializer just because it returns a concrete type.
Since `simplifyRestrictedConstraintImpl` has both parent types and
does nested type matching it's a good place to diagnose top-level
contextual problems like mismatches in underlying types of optionals.
Introduce support for initialized let/var declarations within function
builder closures, e.g.,
let (a, b) = c()
We generate constraints for the declarations as elsewhere, but the types of
the declared variables (a and b in this case) are bound to the type of the
pattern by one-way constraints, to describe the flow of type information
through the closure.
Implements rdar://problem/57330696.
* [CSDiagnostics] Offer a fix-it to insert a return type when returning from a void function
* [CSDiagnostics] Make sure the function name is not empty
The function name will be empty in some cases, for example for property setters. In cases where the function name is empty, skip the note and fix-it.
* [Test] Update existing diagnostics
Fix a case where favoring didn't account for "bound" type variable
being wrapped into optional(s) (disjunctions like that are used for
optional conversions). Doing so makes sure that closure result type
is not bound before the body of the closure is "opened", that's
important because body could provide additional context required
to bind result type e.g. `{ $0 as? <Type> }`.
Resolve: rdar://problem/59208419
When it comes to contextual mismatches `ContextualType` is not guaranteed
to be the last element in the patch since contextual type could be a function
too which could would have `contextual type -> function argument` path.
If parameter type is optional let's ignore that since argument could
be either optional itself or be injected into optional implicitly.
```swift
func foo(_: ((Int, Int) -> Void)!) {}
foo { _ in } // Missing second closure parameter
```
If the type used in for-each loop doesn't conform to `Sequence`
let's not try to diagnose anything about its element since such
diagnostics would include unresolved types and actual problem
(missing conformance) would already be diagnosed.
if the closure had a function builder transform applied.
This way, function builder closures can have syntactic restrictions
diagnosed the same way as other expressions.
Fix a few related issues involving the interaction with
single-expression closures:
* A single-expression closure can have a "return" in it; in such
cases, disable the function-builder transform.
* Have the function builder constraint generator look through the
"return" statement in a single-expression closure the same way as
solution application does
Fixes rdar://problem/59045763, where we rejected some well-formed code
involving a single-expression closure with a "return" keyword.
Originally type mismatches associated with conversions between
function types were only covered for coercions and assignments
but fix coverage grew since then and now it makes sense
to remove special case and let `repairFailures` take care of it.
The fix for <https://bugs.swift.org/browse/SR-10466> did not handle
properties because those types are resolved using the archetype
resolver.
We would bail out early because of a bogus early return that can
just be removed.
Fixes <rdar://problem/45271663>.
Stop filtering outer overload choices while trying to pre-check
expression, instead have it always fetch those and use new
fix to only attempt them in diagnostic mode (unless it's min/max
situation with conditional conformances).
where the base does not conform to the associated type's protocol.
We can only reach this case when the solver has already applied a fix for
the conformance failure.
If a type variable representing "function type" is a hole
or it could be bound to some concrete type with a help of
a fix, let's propagate holes to the "input" type. Doing so
provides more information to upcoming argument and result matching.
Set the contextual type of conditional expressions (to Bool) with the
"condition" purpose so we get customized diagnostics for mistakes such
as
if x.property = y { }
Prior to this, we'd get generic "() isn't convertible to Bool"
diagnostic. Now we get
use of '=' in a boolean context, did you mean '=='?
