applying `@Sendable` inference for global-actor-isolated function types.
Otherwise, for libraries that do not enable `GlobalActorIsolatedTypesUsability`,
clients that do will encounter mangling mismatches for any library APIs that
have global-actor-isolated function types that are not explicitly `@Sendable`.
The previous commit fixed things like:
```swift
let x: () -> sending String = { "" }
```
This commit fixes this test case:
```swift
let x = { () -> sending String in "" }
```
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)
Due to a missing source location in the implicitly-generated `await` in the
async for loop, we misdiagnosed availability within an `if #available`.
Fixes rdar://128560745.
Type variable reference collector needs to be augmented to collect
type variables associated with pack expansions that a closure references
elements of, otherwise it would get disconnected from the context.
Unify with `CTP_ReturnStmt`, and have the
SyntacticElementTarget carry the ReturnStmt for
regular type-checking, which we can use to record
implied returns.
This wasn't consistently used, and consequently
could result in some expressions getting their
parents invalidated. Instead, replace it with a
query to make sure we don't try and add an
expression we've already computed the parent info
for.
Not quite NFC because apparently the representation bleeds into what's
accepted in some situations where we're supposed to be warning about
conflicts and then making an arbitrary choice. But what we're doing
is nonsense, so we definitely need to break behavior here.
This is setting up for isolated(any) and isolated(caller). I tried
to keep that out of the patch as much as possible, though.
Use an optional isolated parameter to this new `next(_:)` overload to
keep it on the same actor as the caller, and pass `#isolation` when
desugaring the async for..in loop. This keeps async iteration loops on
the same actor, allowing non-Sendable values to be used with many
async sequences.
This couples together several changes to move entirely from
`@rethrows` over to typed throws:
* Use the `Failure` type to determine whether an async for-each loop
will throw, rather than depending on rethrows checking
* Introduce a special carve-out for `rethrows` functions that have a
generic requirement on an `AsyncSequence` or `AsyncIteratorProtocol`,
which uses that requirement's `Failure` type as potentially being part
of the thrown error type. This allows existing generic functions like
the following to continue to work:
func f<S: AsyncSequence>(_: S) rethrows
* Switch SIL generation for the async for-each loop from the prior
`next()` over to the typed-throws version `_nextElement`.
* Remove `@rethrows` from `AsyncSequence` and `AsyncIteratorProtocol`
entirely. We are now fully dependent on typed throws.
We are currently lacking the ability to describe "normal or distributed
actor" with a single protocol in a manner that allows hopping to it,
because `AnyActor` is a marker protocol. Use `Actor` while we sort
this out.
Most clients only want to set one of the two
parameters, split it into `setPattern` and
`setInitContext` (the latter of which now
handles calling `setBinding`).
Use the PatternBindingInitializer context if we
have one. This also uncovered a parser issue where
we would mistakenly create a
PatternBindingInitializer in top-level code after
parsing the initializers.
Introduce a new expression macro that produces an value of type
`(any AnyActor)?` that describes the current actor isolation. This
isolation will be `nil` in non-isolated code, and refer to either the
actor instance of shared global actor in other cases.
This is currently behind the experimental feature flag
OptionalIsolatedParameters.
async for-in loops.
Async iterators are not `Sendable`; they're only meant to be used from
the isolation domain that creates them. But the `next()` method runs on
the generic executor, so calling it from an actor-isolated context passes
non-`Sendable` state across the isolation boundary. `next()` should
inherit the isolation of the caller, but for now, use the opt out.
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`.
These two requests are effectively doing the same thing to two
different cases within CatchNode. Unify the requests into a single
request, ExplicitCaughtTypeRequest, which operates on a CatchNode.
This also moves the logic for closures with explicitly-specified throws
clauses into the same request, taking it out of the constraint system.
