There are some situations where the solver is able to find a valid
solution only during `salvage` (mostly but not limited to unavailable
declarations), which means that we need to keep running `salvage`
even if the diagnostics are suppressed until the underlying issues
in the normal solving mode are fixed.
One of the issues:
```swift
extension Unmanaged {
@inline(__always)
internal static func passRetained(_ instance: __owned Instance?) -> Self? {
guard let instance = instance else { return nil }
return .passRetained(instance)
}
}
```
`.passRetained(instance)` is ambiguous during normal solving but
is able to find a solution during `salvage` because it attemtps
more type bindings.
Resolves: rdar://119001449
The parameter should still have a key path type as its superclass
bound (i.e. `KeyPath<...> & Sendable`), this would be verified by
the attribute checker.
When `InferSendableFromCaptures` feature is enabled `inferKeyPathLiteralCapability`
should examine subscript arguments to determine whether the key path type is
sendable or not, and if so, inform inference to produce `& Sendable` existential
type as a binding. Binding key path type is delayed until all subscript arguments
are fully resolved.
Previous `FunctionArgument` locator didn't make sense because
this type variable doesn't actually represent a parameter but
rather a value generic parameter of the key path subscript index
parameter.
Capability couldn't be determined for expressions like that which
means that inference should be delayed until root becomes available.
Resolves: https://github.com/apple/swift/issues/69936
Move some of the checks from the constraint simplification into
`inferKeyPathLiteralCapability` and start using it for both
inference and constraint simplification.
This flag makes it easier to determine what binding to produce
from the default. In cases where some of the member references
are invalid it's better to produce a placeholder for a key
path type instead of letting the solver to attempt to fix more
contextual problems for a broken key path.
i.e.
`S().f` is sendable if `S()` is a Sendable type
Partial apply and unapplied methods of Sendable types should be
marked as Sendable in the constraint system, including declarations
and unapplied functions as parameters.
Conflicts:
- `lib/AST/TypeCheckRequests.cpp` renamed `isMoveOnly` which requires
a static_cast on rebranch because `Optional` is now a `std::optional`.
Teach the constraint solver about the subtyping rule that permits
converting one function type to another when the effective thrown error
type of one is a subtype of the effective thrown error type of the
other, using `any Error` for untyped throws and `Never` for
non-throwing.
With minor other fixes, this allows us to use typed throws for generic
functions that carry a typed error from their arguments through to
themselves, which is in effect a typed `rethrows`:
```swift
func mapArray<T, U, E: Error>(_ array: [T], body: (T) throws(E) -> U)
throws(E) -> [U] {
var resultArray: [U] = .init()
for value in array {
resultArray.append(try body(value))
}
return resultArray
}
```
