This entails passing a linker flags to Apple linkers when the standard
library is not meant for inclusion in such cache.
For this to have effect on every library, propagate link flags when
building _Concurrency and Observation.
This is needed for Apple internal configurations.
Addresses rdar://120653968
Allow `AsyncSequence.flatMap` to be defined with "incorrect" availability,
meaning that the function can refer to the `Failure` associated type
in its where clause even though the function is back-deployed to
before the `Failure` associated type was introduced.
We believe this is safe, and that this notion can be generalized to any
use of an associated type in a same-type constraint of a function
(yes, it sounds weird), but for now introduce a narrower hack to see
how things work in practice and whether it addresses all of the
source-compatibility concerns we've uncovered.
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.
`AsyncFlatMapSequence` is somewhat troublesome for typed throws,
because it can produce errors from two different sources: the `Base`
async sequence and the `SegmentOfResult` async sequence. However, we
need to pick one `Failure` type for the `AsyncFlatMapSequence`, and
there is no surface-language equivalent to the `errorUnion` operation
described in SE-0413.
So, we do something a little bit sneaky. We effectively require that
`SegmentOfResult.Failure` either be equivalent to `Base.Failure` or be
`Never`, such so that when the async sequence retruned by the closure
throws, it throws the same thing as the base sequence. Therefore, the
`Failure` type is defined to be `Base.Failure`.
This property isn't enforced at the type level, but instead in the
`AsyncSequence.flatMap` signatures: we replace the one signature that
returned `AsyncFlatMapSequence` with three overloads that differ only
in their generic requirements, adding:
1. `where SegmentOfResult.Failure == Failure`
2. `where SegmentOfResult.Failure == Never`
3. `where SegmentOfResult.Failure == Never, Failure == Never` (a
tiebreaker between the two above)
For cases where `SegmentOfResult.Failure` is neither `Never` nor
`Failure`, overloading will choose the `flatMap` function that returns
an `AsyncThrowingFlatMapSequence`. This can mean that existing code
will choose a different overload and get a different type, but other
than the type identity changing, the resulting sequence will behave
the same way.
Start implementing `nextElement()` for the various async sequences
provided by the concurrency library, starting with those that
currently depend on `rethrows` with conformances, an undocumented
feature we're trying to stage out of the language.
With the exception of `AsyncFlatMapSequence`, all of these async
sequences have obvious implementations of `nextElement()`. We'll save
that one for later.
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.
Introduce a new associated type `Failure` into the two protocols involved
in async sequences, which represents the type thrown when the sequence
fails. Introduce a defaulted `_nextElement()` operations that throws
`Failure` or produces the next element of the sequence. Provide a
default implementation of `_nextElement()` in terms of `next()` that
force-cases the thrown error to the `Failure` type.
Introduce special associated type inference logic for the `Failure`
type of an `AsyncIteratorProtocol` conformance when there is no
specific _nextElement()` witness. This inference logic looks at the
witness for `next()`:
* If `next()` throws nothing, `Failure` is inferred to `Never`.
* If `next()` throws, `Failure` is inferred to `any Error`.
* If `next()` rethrows, `Failure` is inferred to `T.Failure`, where
`T` is the first type parameter with a conformance to either
`AsyncSequence` or `AsyncIteratorProtocol`.
The default implementation and the inference rule, together, allow
existing async sequences to continue working as before, and set us up
for changing the contract of the `async for` loop to use
`_nextIterator()` rather than `next()`.
Give `AsyncSequence` and `AsyncIteratorProtocol` primary associated
types for the element and failure types, which will allow them to be
used more generally with existential and opaque types.
The function is marked `noreturn` but the compiler was not able to reason
statically about whether this constraint is met. From code inspection it's
clear that the call to `swift_task_donateThreadToGlobalExecutorUntil()` does
not return, so `swift_unreachable()` can be used to suppress the warning.
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.
The `swift_unreachable()` is currently statically unreachable but we'd like to
leave it in place in case the control flow before it changes in the future.
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.
ASL is deprecated in macOS 10.12. It may be time to transition to os_log now
that deployment targets have been raised to 10.12, but until that project
starts these warnings are just pollution.
Filed rdar://121066531 to track adoption of `os_log()` if appropriate.
Concurrency runtime expects discarding task operation entrypoint
function not to have result type, but the current SILGen
implementation generates reabstraction thunk to convert `() -> Void`
to `() -> T` for the operation function.
Since the `T` is always `Void` for DiscardingTG, the mismatch of result
type expectation does not cause any problem on most platforms, but the
signature mismatch causes a problem on WebAssembly.
This patch introduces new builtin operations for creating discarding
task, which always takes `() -> Void` as the operation function type.
which executor for which type of setting, is consolidated and we have a
single knob we use to determine when to use dispatch as our global
executor.
Radar-Id: rdar://problem/119416196
* docs: improve withTaskCancellationHandler docs
* prefer using non-deprecated withCancHandler method
* Apply suggestions from code review
Co-authored-by: Alex Martini <amartini@apple.com>
---------
Co-authored-by: Alex Martini <amartini@apple.com>
