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.
This applies more annotations in the `INTERNAL_CHECKS_ENABLED` disabled
paths, Windows, 32-bit, and non-ObjC paths. Interestingly enough, there
are a couple of compiler intrinsics which are also uncovered.
This fixes a regression where projects that use the C++ stdlib overlay stop building because of a linker error:
```
ld: Shared cache eligible dylib cannot link to ineligible dylib '@rpath/libswiftCompatibilitySpan.dylib'.
```
Usages of `Span<T>` would generally cause a type metadata accessor to be emitted for `Swift.Span`. This becomes a problem with backdeployment, since Span is partially defined in a compatibility binary.
This change adds `@_alwaysEmitIntoClient` to generic usages of `Span` to prevent the type metadata accessor from being emitted into `libswiftCxx.a`.
rdar://152192080
Reflection metadata lookup failures are notoriously difficult to debug
because there is no error handling in TypeLowering outside of
compile-time #ifdef'd fprintf(stderr) calls. The nicest thing to do
would be to adopt llvm::Expected<> but TypeLowering is also included
in the standard library, which only has access to a tiny subset of the
LLVM Support library. This patch adds a place to store a pointer to
the first encountered error, which can then be converted to an
llvm::Error at the API level.
This teaches ClangImporter to respect the `_Nonnull`/`_Nullable` arguments on templated function parameters.
Previously Swift would only import a non-annotated function overload. Using an overload that has either `_Nonnull` or `_Nullable` would result in a compiler error. The non-annotated overload would get imported with incorrect nullability: Swift would always assume non-null pointers, which was inconsistent with non-templated function parameters, which are mapped to implicitly unwrapped optionals.
With this change all three possible overloads are imported, and all of them get the correct nullability in Swift.
rdar://151939344
In task-to-thread concurrency mode, `_getMainExecutorAsSerialExecutor`
returns `SerialExecutorRef::generic()`, which is, give or take, NULL.
Unfortunately we'd declared it as returning `any SerialExecutor`,
rather than `(any SerialExecutor)?`, and then the `getMainExecutor()`
function was calling `asUnownedSerialExecutor()` on it, which then
crashes.
rdar://153152063
Without this, llvm would sometimes wrongly assume there's no indirect
accesses and the optimizations can lead to a runtime crash, by
optimizing away initializing options properly.
Resolves rdar://152548190
