The _Builtin_float symbols were moved twice, most recently from the OS Darwin library, but previously they were in the embedded @rpath Darwin library. @_originallyDefinedIn doesn't support multiple install names, but it can be replaced with -module-abi-name, and then multiple $ld$previous$ symbols can be used.
Update the Platform and Concurrency magic symbols to use $ld$previous$ everywhere.
rdar://130107191
The move from `@_unsafeInheritExecutor` to `#isolation` for the
with*Continuation breaks code that is using `@_unsafeInheritExecutor` and
calling these APIs. This originally caused silent breakage (which manifest
as runtime crashes), and is now detected by the compiler as an error.
However, despite `@_unsafeInheritExecutor` being an unsafe,
not-intended-to-be-user-facing feature, it is indeed being used, along
with these APIs. Introduce _unsafeInheritExecutor_-prefixed versions of
the `with*Continuation` and `withTaskCancellationHandler` APIs into
the _Concurrency library that use `@_unsafeInheritExecutor`. Then,
teach the type checker to swap in these
_unsafeInheritExecutor_-prefixed versions in lieu of the originals
when they are called from an `@_unsafeInheritExecutor` function. This
allows existing code using `@_unsafeInheritExecutor` with these APIs
to continue working as it has before, albeit with a warning that
`@_unsafeInheritExecutor` has been removed.
Fixes rdar://131151376.
https://github.com/swiftlang/swift/pull/72612 can be reverted because it is no
longer necessary for the interface of the stdlib to be compatible with
compilers without `$TypedThrows` support.
`SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY` just means that the global
executor is cooperative, but it doesn't mean that the target platform is
always single-threaded. For example, on wasm32-unknown-wasip1-threads,
the global executor is cooperative, but users can still set up their own
TaskExecutor with multiple threads.
This patch guards the `TaskGroup` state with a mutex even with a
cooperative executor by respecting threading package instead. This
change effectively affects only wasm32-unknown-wasip1-threads.
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.
While the new parameter is added in a compatible way where code which
does not refer to it will get a defaulted nil value; since we refer to a
new parameter name in source, we need to guard it with a language
feature -- as old compilers will not have this new name available.
This should prevent a potential condfail issue.
* [Concurrency] Fix task excutor handling of default actor isolation
The task executor API did not properly account for taking the default
actor locking into account when running code on it, we just took the job
and ran it without checking with the serial executor at all, which
resulted in potential concurrent executions inside the actor --
violating actor isolation.
Here we change the TaskExecutor enqueue API to accept the "target"
serial executor, which in practice will be either generic or a specific
default actor, and coordinate with it when we perform a
runSynchronously.
The SE proposal needs to be amended to showcase this new API, however
without this change we are introducing races so we must do this before
the API is stable.
* Remove _swift_task_enqueueOnTaskExecutor as we don't use it anymore
* no need for the new protocol requirement
* remove the enqueue(_ job: UnownedJob, isolatedTo unownedSerialExecutor: UnownedSerialExecutor)
Thankfully we dont need it after all
* Don't add swift_defaultActor_enqueue_withTaskExecutor and centralize the task executor getting to enqueue()
* move around extern definitions
These APIs remained to preserve source compatibility during bringup. We do not
want them used in swift 6 mode... so deprecate in swift 5 and obsolete in swift
6.
This reverts c07aa9c425 which was done to
avoid a crash in optimnized caused by this PR:
https://github.com/apple/swift/pull/41088
Since this was almost 2 years ago, we probably don't have this issue
anymore as far as I can see other resolved issues, so try to remove the
workaround.
Resolves rdar://88711954
