- Overflow checks added for recent additions to pointer arithmetic (rounding and property pointers).
- The basic `advanced(by:)` functions will need to be dealt with separately.
- The old implementation of `UnsafePointer.withMemoryRebound` had no preconditions.
- When implementing SE-0333, we forwarded the old entry point to the new implementation, which has preconditions.
- This change removes the precondition from the compatibility entry point, reverting it to its previous behaviour.
- This resolves rdar://90462471
* [stdlib] relax stride check
- The stride check in `UnsafePointer.withMemoryRebound` makes less sense when rebinding memory for a single element.
- This skips the stride-matching portion of the `_debugPrecondition` in `withMemoryRebound` when `count == 1`.
* [test] UnsafePointer.withMemoryRebound with capacity 1
- The stride check in `UnsafePointer.withMemoryRebound` makes less sense when rebinding memory for a single element.
- This skips the stride-matching portion of the `_debugPrecondition` in `withMemoryRebound` when `count == 1`.
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 fixes the Windows platform, where the aligned allocation path is
not malloc-compatible. It won't have any observable difference on
Darwin or Linux, aside from manually allocated memory on Linux now
being consistently 16-byte aligned (heap objects will still be 8-byte
aligned on Linux).
It is unfortunate that we can't guarantee Swift-allocated memory via
Unsafe*Pointer is malloc compatible on Windows. It would have been
nice for that to be a cross platform guarantee since it's normal to
allocate in C and deallocate in Swift or vice-versa. Now we have to
tell developers to always use _aligned_malloc/_aligned_free when
transitioning between Swift/C if they expect their code to work on
Windows.
Even though this fix isn't required today on Darwin/Linux, it makes
good sense to guarantee that the allocation/deallocation paths are
consistent.
This is done by specifying a constant that stdlib can use to round up
alignment, _swift_MinAllocationAlignment. The runtime asserts that
this constant is greater than MALLOC_ALIGN_MASK for all platforms.
This way, manually allocated buffers will always use the aligned
allocation path. If users specify an alignment less than m
round up so users don't need
to pass the same alignment to deallocate the buffer). This constant
does not need to be ABI.
Alternatives are:
1. Require users of Unsafe*Pointer to specify the same alignment
during deallocation. This is obviously madness.
2. Introduce new runtime entry points:
swift_alignedAlloc/swift_alignedDealloc, introduce corresponding
new builtins, and have Unsafe*Pointer always call those. This would
make the runtime API a little more obvious but would introduce
complexity in other areas of the compiler and it doesn't have any
other significant benefit. Less than 16-byte alignment of manually
allocated buffers on Linux is a non-goal.
Ensure that UnsafeMutablePointer.deallocate has the alignment that was
used when invoking UnsafeMutablePointer.allocate. This is required to
ensure that the appropriate `free` function is invoked. We would
previously fail on Windows as the allocation would use `malloc` and due
to the value being `-1`, use `_aligned_free` instead when deallocating.
- Fix error in `last(where:)` example
- Improve MemoryLayout, UnsafePointer, and integer operator discussions
- Clean up ranges and random APIs
- Revisions to overflow operators and the SignedNumeric requirements
- Standardize on 'nonoptional' in remaining uses
- Revise Bool.toggle() discussion and fix attribute placement
- Revise to Hasher abstracts and discussions
- Correct the name of the remainder operator
- Clean up deprecations and paste-os w/in UnsafePointer
