Emit and resolve idValue of KeyPath as an absolute pointer if relative
function pointer is turned-off on Wasm target.
The existing ABI can't distinguish an idValue between function pointer
or data pointer in use-site at compile-time and also at runtime. So this
patch adds a new id resolution scheme `ResolvedAbsolute` to distinguish
them at runtime properly.
When SWIFT_COMPACT_ABSOLUTE_FUNCTION_POINTER is enabled, relative direct
pointers whose pointees are functions will be turned into absolute
pointer at compile-time.
Starting with Android 11, AArch64 placed a tag in the top byte of pointers to
allocations, which has been slowly rolling out to more devices and collides
with Swift's tags. Moving these tags to the second byte works around this
problem.
Moved the _gCRAnnotations declarations to their own object module,
which will help to avoid duplicate symbol problems (at least with .a
files).
Also tweaked things to make it so that the demangler and runtime
versions of the message setting code will interoperate (and so that
they'll interoperate better with other implementations that might
creep in from somewhere, like the one in LLVMSupport).
rdar://91095592
If the replacement collection is a fast UTF-8 substring, we can simply
access its backing store directly — we don’t need to use a circuituous
lazy algorithm.
These weren’t doing the right thing, and all callers have now
migrated to the new `_StringGuts.validate*` methods, which combine
bounds checks with encoding validation and scalar alignment.
Also, in UTF-16 slices, forward collection methods to the base view
instead of `Slice`, to make behavior a bit easier to understand.
(There is no need to force readers to page in `Slice`
implementations _in addition to_ whatever the base view is doing.)
Also, in UTF-8 slices, forward collection methods to the base view
instead of `Slice`, to make behavior a bit easier to understand.
(There is no need to force readers to page in `Slice`
implementations _in addition to_ whatever the base view is doing.)
- 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
