First, just call an async -> T function instead of forcing the caller
to piece together which case we're in and perform its own copy. This
ensures that the task is actually kept alive properly.
Second, now that we no longer implicitly depend on the waiting tasks
being run synchronously, go ahead and schedule them to run on the
global executor.
This solves some problems which were blocking the work on TLS-ifying
the task/executor state.
This is conditional on UseAsyncLowering and in the future should also be
conditional on `clangTargetInfo.isSwiftAsyncCCSupported()` once that
support is merged.
Update tests to work either with swiftcc or swifttailcc.
* Implementations for operators and async functions on AsyncSequence per SE-0298
* Add trailing new lines to AsyncSequence adopter files
* Remove extra // from preambles
* Transition sequence properties and sequence initializers to internal
* Rename Upstream to Base
* Rename "Failable" asynchronous sequences to "Throwing"
* Make iteration consistent with closure lifetimes and track failure via state
* Use for await syntax for async function extensions on AsyncSequence
* Work-around rethrows calculations being incorrect for conformance + closure rethrowing
* Update testing names to reflect Throwing versus Failable
* Incorperate runAsyncAndBlock into the test function for suite calls
* Remove @frozen from AsyncSequence operators
* Back out reduce family functions for now due to IRGen bug
* Additional corrections for throwing cases and fix up potential linux crasher
* Add a upstream and throwing tests and correct flatMap's throwing behavior
* Unify parameter names to count
* Add a more helpful precondition on prefix
* Add tests for throwing cases of non closure async functions on AsyncSequence
* Correct missing count transition in dropFirst
* Correct missing , in assertion
* [NFC] add commentary on optimization in dropFirst on dropFirst
* Disable collect tests for non macOS platforms for now
* Disable all async sequence tests for non macOS platforms for now
- introduce UnsafeCurrentTask
- implement Hashable, Equatable on tasks
- assume we'll have a way to get a task from sync context
- Task.Handle now has a Failure type as well
- Task.Handle.getResult
Previously, the error stored in the async context was of type SwiftError
*. In order to enable the context to be callee released, make it
indirect and change its type to SwiftError **.
rdar://71378532
We don't want people using this as a means of jumping from synchronous
code to async code. It blocks the thread that it's running on and spawns
a new thread to run the async code.
This has a couple of drawbacks. First, if it blocks a thread that is
needed by the async code (i.e, calling something on the main actor while
blocking the main thread), it is an immediate deadlock. This is a bad
day for everyone. Second, it can easily lead to thread-explosions.
The proper entry-point for async code is to use something of the
following form:
```
@main
struct Main {
static func main() async {
// ...
}
}
```
This should take care of most new code. There are still places where
folks will need to jump from synchronous code to async code. That still
needs to be designed and implemented, but we don't want people to come
to rely on `runAsyncAndBlock`.
The goal of doing this is to reduce the amount of boilerplate and repeated code w.r.t. Continuation. Having just added `resume()` in four places, I got the sense that there was a lot of common code that was being duplicated. I removed the Throwing variants of these types (they can be expressed as Continuation<T, E:Error> instead of ThrowingContinuation<E>) and I broke out a significant amount of common code between CheckedContinuation and UnsafeContinuation into an implementation-only protocol to avoid repeating it. D.R.Y.
This change resolves rdar://74154769.
This change implements the changes proposed in swift-evolution PR #1264.
Existing test coverage should be sufficient here since the added function
simply calls into the existing `resume(returning:)` function.
This change resolves rdar://74031110.
* [Concurrency] Build C only libdispatch before Swift on non-Darwin platforms
_Concurrency depends on libdispatch and since it is not available by
default on non-Darwin platforms, it needs to be built before the Swift
project, so that the dependency can be resolved.
* Fix clibdispatch installation and BuildSystem tests
* Fix build system tests on Darwin and formatting
By making ConcurrentValue a marker protocol, it no longer has any ABI
impact whatsoever. Sink it down into the Standard Library so it's
easier to use, even from code that isn't building with concurrency
enabled.
The ConcurrentValue protocol indicates when a particular type is safe
to share in a concurrent context, e.g., that a copy of a given value
can be safely used concurrently with the value.
The async handler code doesn't really run concurrently with where it is
launched, despite the implementation currently using `runDetached`
internally. Drop the @concurrent and bitcase it back on when needed.
Debugging tools can use _swift_concurrency_debug_asyncTaskMetadata to identify memory blocks as async task allocations by looking at their isa/metadata pointer.
rdar://72906895
