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.
automatically.
This commit also renames `ConstraintSystem::recordHole/isHole` to
`recordPotentialHole` and `isPotentialHole` to make it clear that
we don't know for sure whether a type variable is a hole until it's
bound to unresolved.
all cases of missing generic parameters.
In `ComponentStep::take` when there are no bindings or disjunctions, use hole
propagation to default remaining free type variables that aren't for generic
parameters and continue solving. Rather than using a defaultable constraint for
holes, assign a fixed type directly when we have no bindings to try.
This is because we already emit a diagostic to tell the user that the property's type does not match the wrappedValue type, so this diagnostic can be a bit confusing especially because the initializer is synthesized
This commit changes the behaviour of the error for
passing a temporary pointer conversion to an
@_nonEphemeral parameter such that it doesn't
affect overload resolution. This is done by recording
the fix with an impact of zero, meaning that we don't
touch the solution's score.
In addition, this change means we no longer need
to perform the ranking hack where we favour
array-to-pointer, as the disjunction short-circuiting
will continue to happen even with the fix recorded.
Diagnose ephemeral conversions that are passed to @_nonEphemeral
parameters. Currently, this defaults to a warning with a frontend flag
to upgrade to an error. Hopefully this will become an error by default
in a future language version.
If the last parameter is defaulted, there might be
an attempt to use a trailing closure with previous
parameter that accepts a function type e.g.
```swift
func foo(_: () -> Int, _ x: Int = 0) {}
foo { 42 }
```
Resolves: rdar://problem/55102498
