We were creating the JumpDests too early, so lowering a 'break' or 'continue'
statement would perform cleanups that were recorded while evaluating the
pack expansion expression, which would cause SIL verifier errors and
runtime crashes.
- Fixes https://github.com/swiftlang/swift/issues/78598
- Fixes rdar://131847933
Instead of copying the data and the type and witnesses separately, use the size in the value witness table and copy everything at once.
copyTypeInto assumed the type was an ordinary existential. When it was actually an extended existential, it would do an incorrect cast and read part of a pointer as the number of witness tables to copy. This would typically result in a large buffer overflow and crash. At this point we already know the type's size, so we can use that info directly rather than essentially recomputing it.
rdar://163980446
This is currently disabled by default. Building the client library can be enabled with the CMake option SWIFT_BUILD_CLIENT_RETAIN_RELEASE, and using the library can be enabled with the flags -Xfrontend -enable-client-retain-release.
To improve retain/release performance, we build a static library containing optimized implementations of the fast paths of swift_retain, swift_release, and the corresponding bridgeObject functions. This avoids going through a stub to make a cross-library call.
IRGen gains awareness of these new functions and emits calls to them when the functionality is enabled and the target supports them. Two options are added to force use of them on or off: -enable-client-retain-release and -disable-client-retain-release. When enabled, the compiler auto-links the static library containing the implementations.
The new calls also use LLVM's preserve_most calling convention. Since retain/release doesn't need a large number of scratch registers, this is mostly harmless for the implementation, while allowing callers to improve code size and performance by spilling fewer registers around refcounting calls. (Experiments with an even more aggressive calling convention preserving x2 and up showed an insignificant savings in code size, so preserve_most seems to be a good middle ground.)
Since the implementations are embedded into client binaries, any change in the runtime's refcounting implementation needs to stay compatible with this new fast path implementation. This is ensured by having the implementation use a runtime-provided mask to check whether it can proceed into its fast path. The mask is provided as the address of the absolute symbol _swift_retainRelease_slowpath_mask_v1. If that mask ANDed with the object's current refcount field is non-zero, then we take the slow path. A future runtime that changes the refcounting implementation can adjust this mask to match, or set the mask to all 1s to disable the old embedded fast path entirely (as long as the new representation never uses 0 as a valid refcount field value).
As part of this work, the overall approach for bridgeObjectRetain is changed slightly. Previously, it would mask off the spare bits from the native pointer and then call through to swift_retain. This either lost the spare bits in the return value (when tail calling swift_retain) which is problematic since it's supposed to return its parameter, or it required pushing a stack frame which is inefficient. Now, swift_retain takes on the responsibility of masking off spare bits from the parameter and preserving them in the return value. This is a trivial addition to the fast path (just a quick mask and an extra register for saving the original value) and makes bridgeObjectRetain quite a bit more efficient when implemented correctly to return the exact value it was passed.
The runtime's implementations of swift_retain/release are now also marked as preserve_most so that they can be tail called from the client library. preserve_most is compatible with callers expecting the standard calling convention so this doesn't break any existing clients. Some ugly tricks were needed to prevent the compiler from creating unnecessary stack frames with the new calling convention. Avert your eyes.
To allow back deployment, the runtime now has aliases for these functions called swift_retain_preservemost and swift_release_preservemost. The client library brings weak definitions of these functions that save the extra registers and call through to swift_retain/release. This allows them to work correctly on older runtimes, with a small performance penalty, while still running at full speed on runtimes that have the new preservemost symbols.
Although this is only supported on Darwin at the moment, it shouldn't be too much work to adapt it to other ARM64 targets. We need to ensure the assembly plays nice with the other platforms' assemblers, and make sure the implementation is correct for the non-ObjC-interop case.
rdar://122595871
This ensures that move checking sees the cleanups when determining a value's lifetime and doesn't
try to insert its own cleanup leading to a double destroy. Fixes#85063 | rdar://163194098.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
This is an experimental feature that is not being actively worked on. Disable
the test when we backwards deploy for now to fix the bots. I am not deleting the
test since it seems to be working on the main bots and it makes sense to at
least keep that going to prevent further breakage.
rdar://159026031
rdar://159143492
Previously all bits after the spare bits of the first element were marked as spare bits. This caused enum tags to be stored in bits used by the payload.
This test sets a specific target triple which is too new for some older OSes. There's no need to run this test in back-deployment testing, so make it only run when testing a fresh-built runtime.
rdar://159026118
The last two tests in the NotPresent test check for fixes that went into 5.3. Testing these against earlier runtimes will fail. Add availability checks so we only test when the fix is present.
While we're here, switch the symbolic references test to use indirect references. Direct references are very likely to pass the test even without the fix, as the reference is likely to point to readable memory. Indirect references make this much more likely to crash by then reading and dereferencing a pointer from the memory the relative pointer points to.
rdar://159034772
rdar://157795547
When types contain stored properties of resilient types, we instantiate their metadata at runtime. If those types are non-copyable, they won't have layout strings, so we must not set the flag.
Tests importing AppKit have a tendency to be flaky when they share a
module cache with other builds using a different set of framework search
flags. Make sure they use a local cache, otherwise the compiler can
reuse incompatible cached modules.
Alternatively, we could align all builds using the same cache to have
exactly the same framework search paths or enable explicit module
builds. I picked the module cache as it's the most reliable solution in
the short and long term.
rdar://142949965
If the base type is composed with marker protocol(s) i.e.
`<<Type>> & Sendable`, let's skip this check because such
compositions are always opened and simplified down to a
superclass bound post-Sema.
Resolves: rdar://148782046
Swift defaults to PIC everywhere. The Swift toolchain clang emits PIC
relocatable objects by default without passing `-fPIC` on Linux, so the
emitted Client.o is relocatable. This is not the case on FreeBSD, where
clang uses the static relocation model by default resulting in a link
failure due to mixing relocations with non-relocatable objects.
```
ld.lld: error: relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC
```
Passing `-fPIC` where needed.
If you had something like:
struct G<T> {
func f<each U>(_: repeat each U) where T == (repeat each U) {}
}
We would fulfill 'each U' from the metadata for 'G<(repeat each U)>',
by taking apart the tuple metadata for `(repeat each U)` and forming
a pack.
However this code path was only intended to kick in for a tuple
conformance witness thunk. In the general case, this optimization
is not correct, because if 'each U' is substituted with a
one-element pack, the generic argument of `G<(repeat each U)>` is
just that one element's metadata, and not a tuple. In fact, we
cannot distinguish the one-element tuple case, because the wrapped
element may itself be a tuple.
The fix is to just split off FulfillmentMap::searchTupleTypeMetadata()
from searchTypeMetadata(), and only call the former when we're in
the specific situation that requires it.
- Fixes https://github.com/swiftlang/swift/issues/78191.
- Fixes rdar://problem/135325886.
