This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
* [IRGen+Runtime] Layout string getEnumTag for fixed size enums subset
getEnumTag impl for layout strings of fixed sized enums that use a function to fetch the enum tag
* Fix potential UB in IRGen
This patch makes the build system to copy the lnk files for each
stdlib targets if needed instead of only for the Linux target.
This is the take 2 of the patch. The first one was reverted in
7aa4a8de06
This patch makes the build system to copy the lnk files for each
stdlib targets if needed instead of only for the Linux target.
Co-authored-by: Max Desiatov <m_desiatov@apple.com>
On Darwin, `RTLD_NEXT` doesn't do what we need it to here, with the
result that if `libswiftCore`'s TSan initializer gets found first,
then `libswift_Concurrency` won't have its initializer called at all,
in spite of us using `RTLD_NEXT` to find the next definition.
Fix this by centralising the initializer in `libswiftCore` instead.
rdar://110665213
Section scans (for metadata, protocols, etc.) can be costly. This change adds tracing calls to those scans so we can more easily see how much time is spent in these scans and where they're initiated.
This adds an os_signpost implementation controlled by SWIFT_STDLIB_TRACING, and a default empty implementation for when that's disabled.
rdar://110266743
We have two stacks that we set up during crash handling, both of
which were potentially misaligned. This only tripped us up on
Ubuntu 20.04 on aarch64 - my guess is that maybe `clone()` aligns
the stack pointer on newer kernels which is why we didn't see it
on 22.04.
rdar://110743884
These seem to be related to signal handling issues in threads that
have been started presumably by the C library or some other library.
Primarily this appears to affect Ubuntu 20.04 on aarch64, though I
have seen sporadic issues on 18.04 as well.
We address the problem by making the thread suspension mechanism
more robust in the face of threads with masked signals.
rdar://110653167
ReflectionContext::allocationMetadataPointer() was reading the
metadata pointer from a wrong offset because of the out-of-sync struct
layouts and dump-generic-metadata was not working correctly.
This change resync's the layouts and adds a static_assert to verify
that the offsets match between GenericMetadataCacheEntry and
GenericCacheEntry.
