On all platforms except Linux, calling `withLockIfAvailable()`
recursively just returns `nil`. However, our Linux implementation
chooses to abort the process instead. We don't need this
inconsistent/destructive behaviour and can just return `nil` as we do
elsewhere.
`pthread_mutex_trylock` return `0` on success.
```
NAME
pthread_mutex_trylock – attempt to lock a mutex without blocking
SYNOPSIS
#include <pthread.h>
int
pthread_mutex_trylock(pthread_mutex_t *mutex);
DESCRIPTION
The pthread_mutex_trylock() function locks mutex. If the mutex is already locked,
pthread_mutex_trylock() will not block waiting for the mutex, but will return an error
condition.
RETURN VALUES
If successful, pthread_mutex_trylock() will return zero, otherwise an error number will
be returned to indicate the error.
ERRORS
The pthread_mutex_trylock() function will fail if:
[EINVAL] The value specified by mutex is invalid.
[EBUSY] Mutex is already locked.
```
To achieve this, add a new cache variable
`SWIFT_EMBEDDED_STDLIB_SDKS_FOR_TARGET_TRIPLES` to be set like in the
following examples.
```
-DSWIFT_EMBEDDED_STDLIB_SDKS_FOR_TARGET_TRIPLES=aarch64-vendor-os@/usr/local/aarch64-vendor-os-sdk;aaarch-vendor-anotheros@/opt/aarch64-vendor-anotheros-sdk
```
We chose to use another setting instead of e.g. folding this into
`SWIFT_EMBEDDED_STDLIB_EXTRA_TARGET_TRIPLES` so it is clear this is opt
in and it does not regress existing configurations that set the SDK
directly (like it's the case for the WASM stdlib).
Addresses rdar://162368529
There has been some discussion as to whether this is the right approach,
centered around internal pointers in the underlying mutex structure.
After much thought, let's commit this for now. The argument:
* While it is true that OpenBSD has futex(2) and in fact is used in
the underlying implementations in Dispatch. I'm not confident right now
creating robust locking primitives by hand from futexes.
It would be ideal to just delegate all of this to Dispatch, but
Dispatch doesn't expose a ready-use API for mutexes. Cobbling one
together might be possible, but that would take some time and finesse.
* While recent versions of C and C++ have language support for mutexes,
they are implemented in many cases by libpthread anyway, so there
is nothing inherently gained right now by not using the pthread API
other than portability.
* While the concern for internal pointers for the pthread API is
important, the OpenBSD is mitigated by the fact that pthread_mutex_t is
pointer-valued on the platform. The concern that this might not always
be the case is mitigated by the fact that this commit does not attempt
to use the pthread implementation as a catch-all for all platforms.
* The alternative is to use MutexUnavailable, but given Foundation has
some dependencies on Mutex, this may cause problems elsewhere
throughout the port.
The _Builtin_float and Synchronization modules are getting the SDK_NAME encoded in their embedded modules, preventing them from being used outside of macOS in embedded mode.
The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
... that would import that as a result of importing Darwin from the SDK.
Amend my previous change to Differentiation and Distributed in this
sense.
Addresses rdar://150400049
This commit adds required conditional compilation blocks to enable bulding on
FreeBSD (tested on x86_64 FreeBSD 14.1-RELEASE-p6). Also implements FreeBSD
synchronization shims using `_umtx_op(2)`
This reverts commit dd037f896f.
@_transparent on deinit was diagnosed as an error in older compilers
Making Atomic.deinit @_transparent will break compiling newer sdk with older compilers
Fixes rdar://139194948
These modules import Darwin which is not in ossa. -enable-ossa-modules
results in a one-time recompilation of dependencies when they are not in ossa.
This is not compatible with Explicit Build Modules when the original invocation
did not have -enable-ossa-modules.
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_swift_target_library was missing pieces for passing sources and
flags to the static SDK build. As a result, the static SDK was missing
pieces (specifically Mutex).
Also adding the Musl import to the Linux Mutex implementation.
- when compiling embedded cross compile target standard libraries, include AVR
- add 16-bit pointer as a conditional compilation condition and get the void pointer size right for gyb sources
- attempt to fix clang importer not importing __swift_intptr_t correctly on 16 bit platforms
- changed the unit test target to avr-none-none-elf to match the cmake build
[AVR] got the standard library compiling in a somewhat restricted form:
General
- updated the Embedded Runtime
- tweaked CTypes.swift to fix clang import on 16 bit platforms
Strings
- as discussed in https://forums.swift.org/t/stringguts-stringobject-internals-how-to-layout-on-16-bit-platforms/73130, I went for just using the same basic layout in 16 bit as 32 bit but with 16 bit pointers/ints... the conversation is ongoing, I think something more efficient is possible but at least this compiles and will probably work (inefficiently)
Unicode
- the huge arrays of unicode stuff in UnicodeStubs would not compile, so I skipped it for AVR for now.
Synchronization
- disabled building the Synchronization library on AVR for now. It's arguable if it adds value on this platform anyway.
