`@export(implementation)` cannot be widely adopted in stdlib yet,
currently leads to condfail in some configrations. Stick to `@_alwaysEmitIntoClient`
for now.
Replace the use of rethrows and #isolation in
withTaskCancellationHandler with typed throws and
nonisolated(nonsending), respectively.
Fixes rdar://146901428.
Replace C++ implementation of swift_beginAccess and swift_endAccess with (almost) pure Swift implementation. Helpers remain in C++ for TLS, getting return addresses, and raising a fatal error on violations.
This change also moves the exclusivity access set head from the shared SwiftTLSContext structure to a dedicated TLS key. This improves performance, which is important for exclusivity checking. This is particularly the case where we can inline TLS access with a constant key, as on Darwin ARM64.
The code that bridges exclusivity tracking into Concurrency remains in C++. The new Swift implementation exposes a few helpers for it to use as a replacement for directly manipulating the C++ implementation.
rdar://161122309
An early check for underflow was a bit too aggressive, resulting in values that
would otherwise round up to the smallest subnormal failing to go through the
regular rounding logic.
Resolves#86462
Resolves rdar://167942063
This is second version of #85621 which was reverted in #85794 because
the result of `_compute_lto_flag` was used as a boolean in some
contexts.
The differences from the original is that `_compute_lto_flag` is split
into a second function `_is_lto_enabled` which provides an actual
boolean for when LTO is enabled, and the half dozen usages of
`_compute_lto_flag` have been audited for using `_compute_lto_flag`
without considering the return value a boolean, or using the new
`_is_lto_enabled` as a proper boolean. A small clean up of commented out
code is performed (probably just a forgetten clean up from #66077).
The changes have been verified by compiling with
`SWIFT_STDLIB_ENABLE_LTO=thin` and
`SWIFT_STDLIB_BUILD_TYPE=RelWithDebInfo`, and checking the resulting
flags for building the stdlib include both `-flto=thin` and
`-gline-tables-only`, while the Swift tools include `-fno-lto` instead.
The following is the original commit message, which explains why this
change is interesting:
---
When compiling Swift as an LLVM external project (not the non-unified
workflow from the build-script), if one tries to enable LTO for LLVM
projects it will end up affecting Swift and the Swift standard library,
even if the options `SWIFT_TOOLS_ENABLE_LTO` and
`SWIFT_STDLIB_ENABLE_LTO` are disabled or using their default values,
because [HandleLLVMOptions] modifies the `CMAKE_C/CXX_FLAGS` globally.
By setting `-fno-lto` explicitly when those options are disabled or
using their default values, the options from `CMAKE_C/CXX_FLAGS` are
overriden, and the `SWIFT_*_ENABLE_LTO` controls the usage or not of LTO
optimizations and the presence of bitcode in the object files.
[HandleLLVMOptions]:
b58b2a34d5/llvm/cmake/modules/HandleLLVMOptions.cmake (L1278-L1310)
We should expose the demangle functionality; It's been widely used by
calling into internal _swift_demangle and instead we should offer a real
API. It's also already used in the Runtime module already when forming
backtraces.
[Previous
discussions](https://forums.swift.org/t/demangle-function/25416/15)
happened between 2019 and 2024, and just never materialized in a
complete implementation and proposal.
Right now, even more tools are in need of this API, as we are building
continious profiling solutions etc, so it is a good time to revisit this
topic.
This PR is roughly based off @Azoy's
https://github.com/swiftlang/swift/pull/25314/files#diff-fd379a721cc9a1c9ef6486eae713e945da842b42170d4d069029a57334371eba
from 2019, however it brings it over to the new Runtime module which is
a great place to put this functionality - even Backtrace had to recently
reinvent calling the demangling infra in this module.
Pending SE review, [proposal
here](https://github.com/swiftlang/swift-evolution/pull/2989).
cc @azoy @al45tair
---------
Co-authored-by: Alastair Houghton <alastair@alastairs-place.net>
The exclusivity enforcement command-line flags currently impact the
generation of SIL within the current module. However, it does not
impact any SIL that was deserialized from another module, which means
that `-enforce-exclusivity=unchecked` doesn't actually remove all of
the dynamic exclusivity checks.
When dynamic exclusivity is disabled, lower SIL
begin_access/end_access instructions to nothing to ensure that we
won't do any dynamic exclusivity checks.
Use this to better model the reality of dynamic exclusivity checking
in Embedded Swift, which effectively turned off all dynamic
exclusivity checking by having empty stub implementations of
swift_(begin|end)Access. Instead, have Embedded Swift default to
`-enforce-exclusivity=unchecked`, so that it never emits calls to
swift_(begin|end)Access. Remove the stub implementations of
swift_(begin|end)Access from the Embedded Swift runtime, since we will
no longer generate calls to them by default.
Moving forward, this will allow us to conditionally enable the new
implementation of dynamic exclusivity checking by specifying
`-enforce-exclusivity=checked` for Embedded Swift builds. We'll stage
that in over time to avoid breaking existing Embedded Swift clients.
This is slightly complicated by us currently not supporting this code
on iOS/tvOS/watchOS/visionOS. We should fix that, at which point we
can use the `SwiftStdlib`/`StdlibDeploymentTarget` macros instead.
rdar://164850733
