This is a partial revert of https://github.com/swiftlang/swift/pull/87360
The change attempted to infer a concrete thrown error type onto
the closure but that leads to incorrect solutions when closure is
passed as an argument to an overloaded declaration because the
solver doesn't check whether calls in the body do throw the
expected type even with `FullTypedThrows` feature enabled
and so the safest option is still to assume un-typed `throws`
unless typed throws comes from a concrete contextual type.
Resolves: rdar://173132715
Previously, we were emitting an unknown pattern error in code like:
```
@MainActor
class MainActorIsolatedKlass {
init() {
Task.detached { @MainActor in
_ = self
for try await x in E.seq {
}
}
}
}
enum E {
static var seq: some AsyncSequence<Float, Error> {
AsyncThrowingStream(Float.self) { $0.finish() }
}
}
```
The issue was that the closure was considered non-Sendable despite being
@MainActor due to the `try await` in it. Investigation revealed an
inconsistency between the constraint solver and getClosureIsolation:
1. In the constraint solver, we were only honoring explicit global actor
isolation for non-async functions, which caused us to not infer that
the closure should have been Sendable despite the try await.
2. Later getClosureIsolation did the correct thing and we labeled the
closure as having global actor isolation, but that did not impact the
actual type of the closure being Sendable at the SIL level.
The result was a non-Sendable main actor isolated closure.
This commit removes the restriction that prevented honoring explicit
global actor isolation for async closures, making the constraint solver
consistent with getClosureIsolation.
rdar://169803154
Normally, an unbound reference to a generic type within its own context is automatically bound to the identity generic arguments:
```
struct G<T> {
typealias TA = G // as if you wrote G<T>
}
```
Module selectors normally disable this kind of contextual behavior; make sure that this is not an exception.
To pipe the information needed to do this through the constraint solver, we extend FunctionRefInfo to remember whether a module selector was used.
ForEach support for Borrowing sequence
For testing purposes, this commit includes _BorrowingSequence and _BorrowingIterator protocols, with conformance for Span and InlineArray.
Still record overload choices for `makeIterator` and `next` when
solving a `ForEachElement` constraint. This maintains compatibility
with the previous behavior where we would solve these in the constraint
system, since the choices can affect ranking if e.g Collection's
default `makeIterator` is compared with a concrete `makeIterator`
overload. This is a complete hack though and we ought to rip this out
as soon as we can.
rdar://168840696
We no longer need to track the `ForEachStmtInfo` in the
`SyntacticElementTarget`, and we can remove the special diagnostic
logic for `next` and `makeIterator` since those are type-checked
separately now.
Make sure we invalidate when we initially visit the ExprPattern to
ensure that we don't run into issues when generating constraints for
a `where` clause before the constraints for the ExprPattern. We ought
to change the constraint generation there to use a conjunction to
ensure that the pattern is solved before the `where` clause, but I
want to keep this as a quick low risk fix that we can cherry-pick. I'll
switch it to a conjunction in a follow-up.
Make sure we don't produce unnecessary diagnostics while still allowing
things like cursor info to work. No test change since it's covered by
the next commit.
We know this is where the issue is so we can immediately bind to a hole,
ensuring we don't produce unnecessary downstream diagnostics from
things we can't infer.
This works around the fact that existential opening does not currently
work correctly in cases where the argument isn't resolved before the
applicable fn is solved.
Add the application constraint before the member constraint, which
allows us to get rid of the special-cased delaying logic for dynamic
member subscripts. The diagnostic change here is due to the fact that
we no longer have a simplified type for the result in CSGen, which
would also be the case if we had a disjunction for the member.
This never worked correctly and would crash in SILGen, ban the use
of placeholder types. While here, ensure we replace any ErrorTypes
with holes when solving the closure in the constraint system.
Since we can run CSGen multiple times, we need to guard the emission
of the note on whether the TypeRepr was already marked invalid (i.e
whether we already emitted a diagnostic for it).
Previously we would skip type-checking the result expression of a
`return` or the initialization expression of a binding if the contextual
type had an error, but that misses out on useful diagnostics and
prevents code completion and cursor info from working. Change the logic
such that we open ErrorTypes as holes and continue to type-check.
Pavel Yaskevich
Slava Pestov
Elsa Keirouz
Michael Gottesman
Pavel Yaskevich
Hamish Knight
Becca Royal-Gordon
elsa
Anthony Latsis
Tim Kientzle