Attempting to favor a disjunction choice here
can lead to unhelpful results if there's e.g a code
completion token argument, since it acts as a
placeholder.
rdar://127844278
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Track the implied result exprs in the constraint
system, and allow arbitrary propagation of
implied results down if/switch expression
branches. This is required for allowing implied
results in non-single-expression closures.
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`.
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
`lookupConformance` request is not cached and constraint solver
performs a lot of them for the same type (i.e. during disjunction
solving), let's try to cache previously performed requests to
see whether additional memory use is worth the performance benefit.
Previously we would only do source ordering for
ClosureExprs, but other conjunctions need to have
their source location taken into account too, in
order to make sure we don't try and type-check e.g
a TapExpr in a second closure before we type-check
the first closure.
Also while here, switch to `std::min_element`
instead of sorting, and treat invalid source
locations as incomparable.
rdar://113326835
Move the contextual type locator onto
ContextualTypeInfo, and consolidate the separate
fields in SyntacticElementTarget into storing a
ContextualTypeInfo. This then lets us plumb down
the locator for the branch contextual type of an
if/switch expression from the initial constraint
generation, rather than introducing it later. This
should be NFC.
