To send them across actors, they need to be wrapped in an '@unchecked
Sendable' type. Typically such a wrapper type would be be responsible
for ensuring its uniqueness or immutability.
Inferring Sendability for arbitrary types that contain Unsafe*Pointers
would introduce race conditions without warning or any explicit
acknoledgement from the programmer that the pointer is in fact unique.
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
These include the pointer-to-pointer and pointer-to-buffer-pointer
initialiser parameters amongst a couple of others, such as
`Unmanaged.fromOpaque`, and the source for the `move[...]` family of
methods.
This improves code generation in -Onone mode. (UnsafeRawPointer.load/.storeBytes isn’t @_transparent and it doesn’t get specialized in unoptimized builds.)
AutoreleasingUnsafeMutablePointer is pointing to a +0 reference, but in its pointee property’s getter/setter implementations, it is loading the pointer into regular Unsafe[Mutable]Pointers. Those are assuming that the addressed memory contain a +1 reference, which can mislead the compiler into doing optimizations that aren’t valid.
Change the getter/setter implementations so that they use UnsafeRawPointer and load/store Unmanaged values instead. As long as Unmanaged.passUnretained(_:) and Unmanaged.takeUnretainedValue() do the right thing, then AutoreleasingUnsafeMutablePointer won’t have issues, either. (This boils down to ensuring that loading a strong reference out of an unmanaged(unsafe) value works correctly.)
This was an ABI break, since it didn't make it into 5.0. Using _read here is unimportant, so we're just going to revert rather than try being fancy.
This reverts commit 04586e3916.
This enables removal of those bridging calls for dead parameters. Read-only lets the optimizer remove such a call if the result is not used.
Note that "readonly" means: no observable write operations. It's okay to allocate and initialize new objects.
rdar://problem/44944094
This hoists out the retain into Swift code from the casting runtime and along a
few paths in the runtime allows us to eliminate a dynamic retain release.
rdar://38196046
rdar://38771331
