Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
**Description**: This adds "task name" parameter to all task creating
functions.
This is done in a few ways, e.g. we can backdeploy this to 5.1 in APIs
which do not accept the `TaskExecutor` but it they do we provide a
version for 6.0+ etc. This was requested in the SE acceptable of this
proposal [Acceptance post
SE-0469](https://forums.swift.org/t/accepted-with-modifications-se-0469-task-naming/79438).
This moves all these declarations to gyb since going through them one by
one has become unmaintainable otherwise.
**Scope/Impact**: All task creation APIs now gain a new task name
parameter.
**Risk:** Medium, changes existing APIs rather than adding "even more
overloads" though this risk was discussed in the team and accepted. This
has a potential to be source breaking it someone used Task.init and
friends as function.
**Testing**: CI testing, source compatibility suite testing
**Reviewed by**:
**Original PR:**
- https://github.com/swiftlang/swift/pull/81107 build changes required
for this
- https://github.com/swiftlang/swift/pull/80984
**Radar:**
---------
Co-authored-by: Kuba Mracek <mracek@apple.com>
This is basically the same as the one for Linux, but it would be
somewhat awkward to add the platform conditional on a file named for
Linux when OpenBSD is not Linux.
Important note: if Dispatch is disabled, then this will cause a
compilation error (probably not just for OpenBSD either), because
PlatformExecutorFactory is both defined in PlatformExecutorNone.swift
and PlatformExecutor<...>.swift in this case.
Because this only bites OpenBSD bootstrap builds, and since OpenBSD
support has been upstreamed to Dispatch, default to the Dispatch
implementation for now to get this in, and we'll refactor in a different
pr.
Swift concurrency defines a default platform executor. This was not
defined for FreeBSD resulting in build failures. Defining it to use the
Dispatch executor.
Scope: This only impacts FreeBSD.
Risk: Low. This change only affects FreeBSD.
Reviewers: @compnerd, @ktoso, @al45tair
Testing: Local testing to ensure Concurrency builds on FreeBSD.
Fixes: rdar://150643436
(cherry picked from commit 4a41e50730)
This is needed for internal Apple configurations that build the Embedded
Stdlib on its own.
Addresses rdar://149410405
(cherry picked from commit a249e7fd8d)
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
(cherry picked from commit 0100104ff7)
WASI with Embedded Swift provides WASI-libc and libc++ headers necessary to build the `_Concurrency` module for Wasm. We now add `wasm32-unknown-wasip1-wasm` triple to `EMBEDDED_STDLIB_TARGET_TRIPLES` when `SWIFT_WASI_SYSROOT_PATH` is set, which builds the necessary stdlib slice.
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
Fix a typo that caused us to not include the correct code for platforms
that use "singlethreaded" concurrency.
Also use `var` not `let` for the computed property in `PlatformExecutorFactory`.
rdar://141348916
Rename `DispatchTaskExecutor` to `DispatchGlobalTaskExecutor` as we
may want to use the former for an executor that runs things on an
arbitrary Dispatch queue.
Rename `DispatchExecutor` to `DispatchExecutorProtocol`; again, we
might want the name for something else.
Add `@Sendable` attribute to `registerEvent`.
Fix missing `extern "C" SWIFT_CC(swift)` on `_swift_exit` (merge
error).
Remove stray whitespace from `CMakeLists.txt`
rdar://141348916
Reorganise the Concurrency code so that it's possible to completely
implement executors (both main and global) in Swift.
Provide API to choose the desired executors for your application.
Also make `Task.Sleep` wait using the current executor, not the global
executor, and expose APIs on `Clock` to allow for conversion between
time bases.
rdar://141348916
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
We have been only including a subset of files and functionality on Embedded Concurrency, let's instead include all the
source files, and have a fine grained opt out on things that don't yet work. Namely, this is still avoiding clocks, task
sleeping and custom executors.
Add a test for AsyncStream and continuations on Embedded Concurrency.
We were missing a field in `SwiftJob`, which broke various things. To
avoid that problem in future, this PR adds a set of static asserts to
check the layout of various structures and that we're using the same
values as well.
Also added some functions to the ABI, and fixed things so that if you
enable the debug logging the library still builds (there was an extra
`_` in `Actor.cpp` that caused a build failure).
Finally, renamed `Hooks.cpp` to `ConcurrencyHooks.cpp`.
rdar://135380149
C++ executor implementations were `#include`ed into `GlobalExecutor.cpp`,
which makes it difficult to replace the global executor when using the
Embedded Concurrency library. Refactor things so that they build into
separate objects, which means replacing them is just a matter of writing
the relevant functions yourself.
rdar://135380149
Everywhere there's a `SWIFT_MODULE_DEPENDS_LINUX Glibc`, there should be
a corresponding `SWIFT_MODULE_DEPENDS_LINUX_STATIC Musl`.
This usually won't bite us, depending on build order and parallelism, but
I hit one of these yesterday so went looking to see if there were any
others.
rdar://136208589
The Concurrency runtime calculates deadlines for scheduling itself
using `swift_get_time()`; unfortunately, on Windows that was using
`QueryPerformanceCounter()`, while Dispatch uses
`QueryInterruptTimePrecise()`. The problem with that is that the two do
not necessarily correspond *at all*. In general
`QueryPerformanceCounter()` may be using any of a number of hardware
timers depending on the machine on which we're running.
In the VM I was testing on, the two differed by 20ms, but the worst case
is that they are completely unrelated, in which case `Task.sleep()` will
wait essentially a random amount of time.
rdar://135413803
Annotate all of the `Unsafe*` types and `unsafe` functions in the standard
library (including concurrency, synchronization, etc.) as `@unsafe`. Add a
few tests to ensure that we detect uses of these types in clients that
have disabled unsafe code.
Supported older compilers don't enable this feature by default, so it can't be
omitted from the `_Concurrency` module's flags (regression from
https://github.com/swiftlang/swift/pull/74543).
Additionally, remove `@_allowFeatureSuppression(IsolatedAny)` from all
declarations. We no longer need to support compilers that don't have the
`IsolatedAny` feature, so the suppression is superfluous and the alternative
branches didn't actually build anyways. _Additionally_, the suppressible
feature logic could not handle suppressing `IsolatedAny` simultaneously with
`SendingArgsAndResults`, resulting in a broken interface because `sending` was
used outside `#if $SendingArgsAndResults` guards.
To preserve compatibility with older compilers that do not allow `IsolatedAny`
to be enabled in production compilers, use an alias experimental feature when
building the stdlib (`IsolatedAny2`).
Also, add `@_allowFeatureSuppression(IsolatedAny)` in a couple spots it was
forgotten.
Partially resolves rdar://125138945
