Move to a recursive lock inline in the Task. This avoids the need to allocate a lock record and simplifies the code somewhat.
Change Task's OpaquePrivateStorage to compute its size at build time based on the sizes of its components, rather than having it be a fixed size. It appears that the fixed size was intended to be part of the ABI, but that didn't happen and we're free to change this size. We need to expand it slightly when using pthread_mutex as the recursive lock, as pthread_mutex is pretty big. Other recursive locks allow it to shrink slightly.
We don't have a recursive mutex in our Threading support code, so add a RecursiveMutex type.
rdar://113898653
There cannot be undefined behavior at compile time, so these warnings can be
ignored when `offsetof` is used in a static assert:
```
warning: offset of on non-standard-layout type 'AsyncTask' [-Winvalid-offsetof]
```
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.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
This is set to hidden in `stdlib/CMakeLists.txt`, but in some Apple
internal configurations we build the compatibility archives by directly
importing `stdlib/toolchain`, thus skipping these directives and
causing some symbols to become unexpected visible.
Addresses rdar://73709695
`__builtin_available` requires linking compiler-rt, which
is not easier to do within the backward compatibility libraries.
Instead, use an API that's been in the standard library since before
Swift 5.0 for the version check.
The back-deployed concurrency library, which is used on OS versions
prior to the introduction of concurrency, has a Swift 5.6-era
concurrency library that supports vouchers.
The introduction of the library providing back-deployment fixes for
Swift 5.6 concurrency libraries (and older) introduced a concurrency
crash in the following OS version ranges
- macOS [12.0, 12.1)
- iOS [15.0, 15.1)
- tvOS [15.0, 15.1)
- watchOS [8.0, 8.2)
Neither older nor newer versions of the listed OSs were affected.
The actual bug involved a miscommunication between the code in the
library that back-deploys fixes (`libswiftCompatibility56.a`) and the
concurrency library in the OS itself. Specifically, the OS versions at
the end of the ranges above introduced voucher support into the
concurrency runtime in the OS (an important feature for performance).
The code in `libswiftCompatibility56.a` that back-ports concurrency fixes
also included the voucher support, which provides a consistent state
for those OS versions and anything newer.
OS versions that predate the introduction of concurrency in the OS are
similarly unaffected, because the embedded
`libswift_Concurrency.dylib` matches that of Swift 5.6, which includes
voucher support.
The OS versions in the affected range include a concurrency library in
the OS that does not manage vouchers. The `libswiftCompatibility56.a`
back-deployed fixes library has code that works on the same data
structures but does manage vouchers, leading to crashes when (say) a
job allocated by the OS version didn't set the "voucher" field, but
the `libswiftCompatibility56.a` tried to free it, essentially a form of
overrelease.
The fix is to teach the voucher-handling code in
`libswiftCompatibility56.a` to first check what version of the OS it
is executing on. If it's in the affected range, all handling of
vouchers is disables so it acts like the concurrency library in the
OS. For both earlier OS versions and later OS versions the
voucher-handler code executes unchanged. This entirely library is
disabled when running on OS versions containing the Swift 5.7
concurrency library (or newer), so those don't need to pay for the
extra check when dealing with vouchers.
Fixes rdar://108837762, rdar://108864311, rdar://108958765.
Apparently `-fvisibility=hidden` is not sufficient to hide some of the
symbols in this library. I've explicitly marked the symbols that were
flagged as being incorrectly exported as "hidden" so hopefully no one
drags them out again.
This is a statically linked library, so the symbols shouldn't need to be
exported for this work work. To ensure that this is the case and that
we're still hitting the overridden API with all of the hidden symbols, I
added a debug log line to the fixed `AsyncTask::waitFuture`
implementation and have verified that we see the compat56 log message
emitted from executables that need the compat56 library.
The threading library changed in the BackDeployConcurrency library
resulting in the `SWIFT_TASK_DEBUG_LOG` macro not compiling. Fixing
that. Also adding the logging pieces to the Compatibility 56 library.
I seem to have copied over the wrong version of Task.h. There is an ABI
mismatch in the size of AsyncContext due to the removal of Flags. This
resulted in programs crashing when running against the backdeploy
library and should have crashed when running on the swift 5.6 runtime.
The successResultPointer pointer was set in AsyncTask::waitFuture, but
with the wrong layout. When the pointer was read in the concurrency
backdeploy library, it was at a different offset, and thus contained a
nullptr.
I pulled the AsyncContextKind and AsyncContextFlags from the old
MetadataValues.h into Task.h as they were removed in commit
aca744b211, but are necessary with the
flags included.
This patch replaces the platform version check with a dlsym to grab the
symbol we need. If we're on a new enough platform, the symbol should be
available and we can use it. Otherwise, it will be empty and we should
return true. This breaks the link requirement for the platform version
symbol.
If we include this file, it generates inline assembly, which would be fine
except that when apps are being built with bitcode, that isn't allowed.
rdar://103274667
Upstream build system zippering support.
Setting the `SWIFT_ENABLE_MACCATALYST` flag will build the compatibility
libraries with zippering enabled.
Note that AppleClang and LLVM Clang use different flags to write
zippered files. The Swift stdlib build doesn't know what clang we're
using, so we can't ask it for the compiler ID to determine which whether
we're using AppleClang or LLVM clang, hence the nasty `execute_process`
trick to figure out whether the compiler that's actually compiling the
stdlib knows about the flag or not.
I keep trying to fix the tsan symbol dance, avoiding duplicate symbols
for initializing the tsan acquire and release function pointers. The
idea this time was to expose an API from the runtime to return the
function pointers for the compatibility library. This won't work because
the compatibility library would need to backdeploy to a version of the
library that doesn't have those symbols, so it would fail to link.
Now, if I really wanted to increment the counter again, an idea might be
to pull the swift_tsan_acquire/swift_tsan_release symbols out of the
Swift concurrency runtime and make them into a toolchain static library
which would get linked by the driver when doing an ASAN build. The
sanitizer libraries are already shipped like this, so it wouldn't be
too weird to do this.
We were detaching the child by just modifying the list, but the cancellation path was assuming that that would not be done without holding the task status lock.
This patch just fixes the current runtime; the back-deployment side is complicated.
Fixes rdar://88398824
Removing
- swift_task_localValueGetImpl
- swift_task_localValuePopImpl
- swift_task_localsCopyToImpl
- swift_task_reportIllegalTaskLocalBindingWithinWithTaskGroupImpl
These static functions are not used or exported from the 5.6 backdeploy
library.
Symbols from the backdeploy libraries shouldn't be exported by dylibs.
Also found an undefined declaration (asyncMainDrainQueue) and a
duplicate declaration for `swift_task_getCurrent`, so those were cleaned
up.
* Backdeploy swift_task_future_wait
This patch adds the implementation for `swift_task_future_wait`
entrypoint to the backdeploy library.
This involves pulling in `AsyncTask::waitFuture`, which relies on a fair
bit.
Please note, this pulls in the `StaticMutex` implementation from Swift
5.6. There are some challenges here. The concurrency version of the
`StaticMutex` involves a fairly nasty set of ODR violations in the
normal setup. See `public/Concurrency/Mutex.cpp`, which includes the
Mutex implementations cpp files directly, while defining a single macro
to replace the implementation of swift::fatalError with
swift_concurrency_fatalError. We only need the concurrency mutex (at
least for now), so I have hard-coded the `swift_concurrency_fatalError`
version into this library. If we should need the other implementation,
we are forced to include ODR-related undefined behavior.
We need symbols from C++, so I've added an implicit linker flag whenever
the static library is used, namely, it passes `-lc++` to the linker.
Since we only backdeploy on Apple platforms, this should be fine.
Some of the platform runtimes we need to backdeploy to have the
enter/exitThreadLocalContext functions defined, while others don't. We
define our own backdeploy56 shim function that dlsym's the function
pointer for these symbols if we have exclusivity checking available.
Otherwise, it doesn't do anything. If concurrency exclusivity checking
is available, we'll use it, otherwise we wont'.
The same dlsym check is done for `swift_task_escalate`. Not all
platforms we need to backdeploy to have a concurrency runtime. The
symbols that do need to use pieces of the concurrency runtime should not
be getting hit when deploying to systems that don't have concurrency. In
the event that you've gotten around the language blocking you from
calling these symbols and you've managed to call concurrency pieces
without using concurrency, we'll abort because something is seriously
wrong.
* Backdeploy swift_task_future_wait_throwing
Drop the remaining pieces in for adding
`swift_task_future_wait_throwing`.
* Apply task_wait_future fix
Actually apply the fix from ef80a315f8.
This deviates slightly from the original patch.
AsyncTask::PrivateStorage::_Status() does not exist in the Swift 5.6
library. Instead I am using `AsyncTask::PrivateStorage::Status`.
* Workaround missing compiler-rt linking
Working around the missing link against compiler-rt in these test.
They are a bit brittle as if anything in them uses compiler-rt, they
will start failing. The backdeploy 5.6 library uses some symbols from
compiler-rt, thus causes them to fail to link.
Disabling the runtime compatibility version checking to avoid these
symbols. This should be fine for the MicroStdlib test, but we should fix
'%target-ld' to handle this better in the future.
rdar://100868842
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
This patch removes the implementation implementations and just calls the
original symbol without the fixes. This allows the library to build and
for binaries to link against it without breaking anything with missing
symbols.
This patch gets everything to the point of building the library, but it
doesn't run yet since I have missing symbols.
Unlike previous compatibility libraries and the concurrency
compatibility library, I'm organizing the headers a bit more. This is
because we're merging the two libraries into one. They share some common
header names, and while I could rename them for namespacing purposes,
it's easier to just use a directory structure for this.
The `include/Runtime` and corresponding `Runtime/` directories are for
backdeployed changes to the stdlib itself.
The `include/Concurrency` and corresponding `Concurrency/` directories
are for backdeployed changes to the concurrency runtimes.
