It's only needed in one place in the constraint solver to allow
`() -> T` to `() -> ()` and `() -> Never` to `() -> T` for expressions
representing return of a single expression functions, so to simplify
contextual type handling in diagnostic and other places it would be
better to replace dedicated locator kind with a flag on existing `ContextualType`.
Resolves: rdar://problem/51641323
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.
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.
This fixes an oversight related to `ReferenceWritableKeyPath` overloads
of the KeyPath dynamic member lookup. Original check filtered out only
`WritableKeyPath` if the storage is read-only, but it should check for
both `WritableKeyPath` and `ReferenceWritableKeyPath`, otherwise program
is going to crash at run time.
Resolves: rdar://problem/51456614
Add `llvm_unreachable` to mark covered switches which MSVC does not
analyze correctly and believes that there exists a path through the
function without a return value.
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
As part of the `DefineBasedOnUse` fix introduced in places where
there is a reference to non-existent member, let's also add
constraints which allow to default any generic parameters found
in base type to `Any`.
All places where `invalid member ref` fix/diagnostic is used already
have a reference to the potential member choice declaration, which
diagnostic could take advantage of.
Extend use of `missing protocol conformance` fix to cover contextual
failures, such as:
- Assignment mismatches, where destination requires source to conform
to certain protocol (or protocol composition);
- Incorrect returns where returned type doesn't conform to the
protocol specified in the signature.
Extend use of `missing protocol conformance` fix to cover contextual
failures, such as:
- Assignment mismatches, where destination requires source to conform
to certain protocol (or protocol composition);
- Incorrect returns where returned type doesn't conform to the
protocol specified in the signature.
Detect and diagnose a contextual mismatch between expected
collection element type and the one provided (e.g. source
of the assignment or argument to a call) e.g.:
```swift
let _: [Int] = ["hello"]
func foo(_: [Int]) {}
foo(["hello"])
```
Instead of always requiring a call to be made to pass argument
to `@autoclosure` parameter, it should be allowed to pass argument
by value to `@autoclosure` parameter which can return a function
type.
```swift
func foo<T>(_ fn: @autoclosure () -> T) {}
func bar(_ fn: @autoclosure @escaping () -> Int) { foo(fn) }
```
We don't require or allow '&' for the mutable parameters in
operator calls, since we want to write 'x += 10' and not
'&x += 10'.
The constraint sovler accepted '&x += 10' though, and we had
a separate pass in MiscDiagnostics for rejecting it.
Instead, let's just reject this in the solver.
The main difficulty is that we must now be prepared to fail
certain OperatorArgumentConversion and ApplicableFunction
constraints even when both the LHS and RHS types are equal.
Now covers following new areas (alongside simple assignments):
- Contextual type coercions:
- In assignment e.g. `let _: X = foo`
- In return type positions e.g. `func foo() -> A { return bar }`
- Argument-to-parameter applications (including @autoclosure)
Diagnose extraneous use of address of (`&`) which could only be
associated with arguments to `inout` parameters e.g.
```swift
struct S {}
var a: S = ...
var b: S = ...
a = &b
```
If "convertTo" type is an optional let's look through it to see
whether it contains another function type which, if so, would
rule out possibility of missing explicit call.
Resolves: rdar://problem/50438071
