The way that we include COMPATIBILITY_OVERRIDE_INCLUDE_PATH freaks out the
syntax highlighting of editors like emacs. It causes the whole file to be
highlighted like it is part of the include string.
To work around this, this patch creates a separate file called
CompatibilityOverrideIncludePath.h that just includes
COMPATIBILITY_OVERRIDE_INCLUDE_PATH. So its syntax highlighting is borked, but
at least in the actual files that contain real code, the syntax highlighting is
restored.
Define `NOMINMAX` and `WIN32_LEAN_AND_MEAN` when including `<Windows.h>`.
Don't export the interface from DLLs.
Make sure we include `<new>` when using placement operator new.
rdar://135380149
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
`ExecutorHooks.h` is now nothing to do with hooks, so rename it. Also
there are some additional functions it should declare, and a couple of
places where we've slightly messed up the boundary, for instance
`swift_task_asyncMainDrainQueue` was defined in `Task.cpp` rather than
in the executor implementations, which is wrong, so fix that too.
`CooperativeGlobalExecutor.cpp` now builds against the interface from
`ExecutorImpl.h`, rather than including the all the concurrency headers.
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
After we've enqueued a job, another thread may run it and destroy it. Don't try to get the job's task executor preference when we try to schedule it. Instead, get the task executor preference before enqueueing the job, then use that preference when scheduling if necessary. Since getting the executor preference is potentially somewhat expensive (we need to search the status records for an executor preference record), only do this if the pre-compare-and-swap states look like they'll need it.
rdar://136281920
- Use the spelling "canceled" per Apple Style Guide
- Use code voice for symbol name
- Use contractions
- Avoid parenthesis for asides
- Change "it" to "that function" to reduce ambiguity
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 `_SwiftConcurrencyShims` module was imported `@_implementationOnly` which
was causing warnings to be emitted during the stdlib build. The module
currently serves no purpose; the only declaration it contains is a defunct
`_SwiftContext` struct which is not referenced by anything. The module needs to
continue to exist for source compatibility, though, since it is part of the
toolchain and imported publicly from other modules.
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
This function is an implementation detail of the runtime, not something that
clients of the _Concurrency library should be able to directly name. Make it
`@usableFromInline internal` instead of `public` so that it remains as ABI but
doesn't show up in auto-complete or documentation.
As of the changes in https://github.com/swiftlang/swift/pull/41713 to
enable Sendability for AsyncStream, it has been possible to create
multiple stream consumers operating concurrently. This change fixes
behavior in the case that the underlying stream is terminated while
multiple pending continuations are outstanding. Previously such
consumers would have been leaked (never resumed). Now, they are notified
of the stream's termination and resumed appropriately.
Resolves#66541 & #71412
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.
