If root type of a key path has been determined to be a hole there
is no reason to delay the inference decision which should be a
failure because none of the components would be inferrable from
a placeholder root.
A reference to a subscript (whether instance or static) produces a
function type, which is then applied as part of an application
constraint. Make sure that we encode whether the subscript can throw,
and the thrown error type if present, in that function type. This lets
us correctly treat subscripts as a potential throw sites.
Start classifying all potential throw sites within a constraint
system and associate them with the nearest enclosing catch node. Then,
determine the thrown error type for a given catch node by taking the
union of the thrown errors at each potential throw site. Use this to
compute the error type thrown from the body of a `do..catch` block
within a closure.
This behavior is limited to the upcoming feature `FullTypedThrows`.
When a file defining an API is included in two modules, clients calling
that API may get an error about the ambiguity on the duplicated API.
That error is not very helpful when it takes into account the
swiftsourceinfo data and points to the source file instead of the
module. In such a case the notes point twice to the same file and line
of code.
Improve this diagnostic by appending the module name to the notes when a
candidate is found outside of the module.
rdar://116255141
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.
