There is a small bug fix here in the identification of the catch node,
where the leading `{` of a closure was considered to be "inside" the
closure for code like
{ ... }()
causing us to assume that the call to the closure would catch the error
within the closure.
Other than that, introduce the thrown error type into the type checker's
modeling of `withoutActuallyEscaping(_:do:)`, and mirror that in the
library declaration.
Enabling typed throws has introduced some spurious warnings about error
values of `Never` type on top of the custom "unreachable" diagnostics
for catch clauses, so suppress the new warnings---they aren't helpful.
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.
