Previously we were just searching for a resolved
overload with the same component index and anchor
for the key path. However unfortunately that found
dynamic member lookup overloads in certain cases,
leading to an incorrect mutability capability.
Change the logic such that it uses the callee
locator for a given key path component, ensuring
we only match against the "direct" callee, and
not any dynamic members it might be also referring
to.
Resolves SR-11896.
It might be either impossible to infer the base because there is
no contextual information e.g. `_ = .foo` or there is something
else wrong in the expression which disconnects member reference
from its context.
If it couldn't be determined precisely what is the structural
difference between two function types, let's still repair the
mismatch by ignoring contextual type.
Initially this problem was only detected and diagnosed for calls.
So let's extend it to function conversions as well e.g.:
```swift
func foo<T>(_: [T]) {}
func bar<T>(_ f: (T...) -> ()) {}
bar { foo($0) }
```
Add a case to getCalleeLocator to return the
appropriate locator for a call to an implicit
callAsFunction member reference.
Resolves SR-11386 & SR-11778.
Locator builders keep a pointer to their underlying
locator, so it's not generally sound to extend an
rvalue locator builder.
This commit enforces that withPathElement is called
on an lvalue, and adds a couple more overloads of
getConstraintLocator to make it more convenient to
extend locators with multiple elements.
Some constraint transformations require knowledge about what state
constraint system is currently in e.g. `constraint generation`,
`solving` or `diagnostics` to make a decision whether simplication
is possible. Notable example is `keypath dynamic member lookup`
which requires a presence of `applicable fn` constraint to retrieve
some contextual information.
Currently presence or absence of solver state is used to determine
whether constraint system is in `constraint generation` or `solving`
phase, but it's incorrect in case of `diagnoseFailureForExpr` which
tries to simplify leftover "active" constraints before it can attempt
type-check based diagnostics.
To make this more robust let's introduce (maybe temporarily until
type-check based diagnostics are completely obsoleted) a proper
notion of "phase" to constraint system so it is always clear what
transitions are allowed and what state constraint system is
currently in.
Resolves: rdar://problem/57201781
Instead of always attempting an optional unwrap fix if types differ
in optionality, let's make it more targeted for each applicable
locator and conversion.
In addition adjust a couple of uses of `ForceOptional` fix to avoid
recording the same fix multiple times and use appropriate `impact`
instead.
diagnosing failures in applySolutionFixes, coalesce fixes and
diagnose failures in one method on ConstraintFix.
This eliminates the need for the `DefaultGenericArgument` fix (which
was renamed from `ExplicitlySpecifyGenericArguments`) to have an
array of missing parameters, which was only used when the fixes were
coalesced. Instead, the coalesced arguments are used to create the
`MissingGenericArgumentsFailure` diagnostic directly.
Detect and diagnose a problem when explicitly specified closure
result type doesn't match what is expected by the context:
Example:
```swift
func foo(_: () -> Int) {}
foo { () -> String in "" } // `Int` vs. `String`
```
Currently `{inout, array, string}-to-pointer` conversion doesn't
track whether there was a difference in optionality between involved
types which leads to ambiguity when different overload choices
have different optionality requirements.
Let's fix that by increasing a score in cases if pointer type
is itself optional e.g.:
```swift
func foo(_ x: UnsafeMutablePointer<Int>) {}
func foo(_ x: UnsafeMutablePointer<Int>?) {}
foo(&foo) // Should pick the least optional overload choice.
```
Resolves: [SR-8411](https://bugs.swift.org/browse/SR-8411)
All of the argument diagnostics have been ported to the new diagnostic
framework, so now is the time to remove `ArgumentMatcher` and the only
place where it was used - `diagnoseSingleCandidateFailures`.
This commit moves the getNSObjectType and
getObjCSelectorType methods from TypeChecker
onto ASTContext. In addition, it moves the
FOR_KNOWN_FOUNDATION_TYPES macro into a separate
file to define each of the Obj-C type decls
we want to have access to.
If the fix is applied to result type of a function or subscript
invocation increase its impact because such uses are invalid
e.g. assigning a value to a function call `foo() = 42`, or
using read-only subscript as mutating.
```swift
struct S {}
protocol P {}
func foo(_ value: S) {
var p: P? = nil
p = value
}
```
Assignment destination is a protocol `P` and source is a type `S`
which doesn't conform to `P`. Allow solver to detect this situation
and record `ignore assignment destination type` fix which would
cover a single missing conformance as well as protocol composition.
