- 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.
* Add missing period at end of sentence
* Add missing period
Co-authored-by: LamTrinh.Dev <me@lamtrinh.dev>
---------
Co-authored-by: LamTrinh.Dev <me@lamtrinh.dev>
The executor may execute and free the task while the enqueue code is still finishing up. If that code tries to get an async backtrace (for example, if it calls malloc/free with malloc stack logging enabled) then it will find a dangling pointer in the current task TSD, and dereferencing it may crash.
rdar://130125017
SWIFT_DEBUG_VALIDATE_UNCHECKED_CONTINUATIONS works by tracking the context pointers of active continuations, and verifying that a resumed context is in the set of active continuations. However, the resume calls are passed the task pointer, not the context pointer. The context pointer is recovered from the task. If the task has been destroyed, the context pointer is invalid. This can result in a weird error message or it can crash if the context pointer is used before checking it against the active continuations.
Instead, track tasks that are suspended pending an unchecked continuation. If the task is destroyed, we'll still be passed the dangling pointer and check that pointer against the tracking info. We must be sure to check that before trying to use anything inside it.
rdar://131858544
Extend the _unsafeInheritExecutor_ workaround to all remaining APIs in the
Concurrency library that have adopted `#isolation` default arguments to
(safely) stay in the caller's isolation domain...
... except one. Clock.measure() is currently running into problems with
the type checker workaround and needs a little more thought.
Fixes rdar://131760111.
It cannot be used for executing general-purpose work, because such function would need to have a different signature to pass isolated actor instance.
And being explicit about using this method only for deinit allows to use object pointer for comparison with executor identity.
