Add SWIFT_DEBUG_ENABLE_TASK_SLAB_ALLOCATOR, which is on by default. When turned off, async stack allocations call through to malloc/free. This allows memory debugging tools to be used on async stack allocations.
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
In some cases, like when building the Swift toolchain build tools,
`SWIFT_STDLIB_LIBRARY_BUILD_TYPES` is not defined. This causes a
configuration failure when the `CompatibilitySpan` library is being
added.
This commit sets a default value of `STATIC` to work around this
problem.
This dynamic library contains a copy of the standard library's
exported entry points for the Span and RawSpan types. This will
allow backward deployment of code that uses those new types.
We have a few constructor functions that aren't wrapped in SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_BEGIN/SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_END and which have started to produce warnings in a new clang version. Explicitly allow these constructors by adding those.
rdar://147703947
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.
We need to make sure that we add the compatibility libraries as
dependencies for target executables, otherwise we can end up with
a race condition in the build where the build will fail if the
compatibility libraries haven't been built by the time e.g.
`swift-backtrace` is linked.
rdar://128197532
check_cxx_compiler_flag caches its results for the same variable, since
all the flags were using the same variable, only the first check was
done, and the rest of the flags were just using the result of the first
flag.
Make each of the check_cxx_compiler_flag use a different variable (by
interpolating the flag name) and reorder the list of compiler flags to
check. -Wall was added twice, and in the case of MSVC, the equivalent
was added last.
It doesn't really seem to affect a lot of things.
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
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
`__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.
rdar://105837040
* WIP: Store layout string in type metadata
* WIP: More cases working
* WIP: Layout strings almost working
* Add layout string pointer to struct metadata
* Fetch bytecode layout strings from metadata in runtime
* More efficient bytecode layout
* Add support for interpreted generics in layout strings
* Layout string instantiation, take and more
* Remove duplicate information from layout strings
* Include size of previous object in next objects offset to reduce number of increments at runtime
* Add support for existentials
* Build type layout strings with StructBuilder to support target sizes and metadata pointers
* Add support for resilient types
* Properly cache layout strings in compiler
* Generic resilient types working
* Non-generic resilient types working
* Instantiate resilient type in layout when possible
* Fix a few issues around alignment and signing
* Disable generics, fix static alignment
* Fix MultiPayloadEnum size when no extra tag is necessary
* Fixes after rebase
* Cleanup
* Fix most tests
* Fix objcImplementattion and non-Darwin builds
* Fix BytecodeLayouts on non-Darwin
* Fix Linux build
* Fix sizes in linux tests
* Sign layout string pointers
* Use nullptr instead of debug value
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
