Add UnsafeRawPointer type and API. #3677
Conversation
|
@swift-ci Please test and merge. |
As proposed in SE-0107: UnsafeRawPointer. https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md The fundamental difference between Unsafe[Mutable]RawPointer and Unsafe[Mutable]Pointer<Pointee> is simply that the former is used for "untyped" memory access, and the later is used for "typed" memory access. Let's refer to these as "raw pointers" and "typed pointers". Because operations on raw pointers access untyped memory, the compiler cannot make assumptions about the underlying type of memory and must be conservative. With operations on typed pointers, the compiler may make strict assumptions about the type of the underlying memory, which allows more aggressive optimization. Memory can only be accessed by a typed pointer when it is currently bound to the Pointee type. Memory can be bound to type `T` via: - `UnsafePointer<T>.allocate(capacity: n)` - `UnsafePointer<Pointee>.withMemoryRebound(to: T.self, capacity: n) {...}` - `UnsafeMutableRawPointer.initializeMemory(as: T.self, at: i, count: n, to: x)` - `UnsafeMutableRawPointer.initializeMemory(as: T.self, from: p, count: n)` - `UnsafeMutableRawPointer.moveInitializeMemory(as: T.self, from: p, count: n)` - `UnsafeMutableRawPointer.bindMemory(to: T.self, capacity: n)` Mangle UnsafeRawPointer as predefined substitution 'Sv' for Swift void pointer ([urp] are taken).
|
@swift-ci Please test and merge. |
| var UnsafeMutableRawPointerExtraTestSuite = | ||
| TestSuite("UnsafeMutableRawPointerExtra") | ||
|
|
||
| class Missile { |
There was a problem hiding this comment.
Why not LifetimeTracked? The harness will do leak checks for you.
There was a problem hiding this comment.
I made a note to follow up on this because I should also change the original UnsafePointer tests. For now the tests are consistent.
|
Assuming this merge goes through, I'll create a new PR with a slew of test case tweaks, comments and formatting based on Dmitri's comments. |
Incorporate Dmitri's feedback. Properly use a _memmove helper. Add load/storeBytes alignment precondition checks. Reword comments. Demangler tests.
|
Don't merge this yet. UnsafePointer mangling test cases don't work for some reason. |
|
@swift-ci Please test and merge. |
|
This depends on a generic substitution feature that need to pull in first. |
|
This passes the "long" tests now. |
|
This symbol is missing from corelibs-foundation: |
[pull] swiftwasm from main
As proposed in SE-0107: UnsafeRawPointer.
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
The fundamental difference between Unsafe[Mutable]RawPointer and
Unsafe[Mutable]Pointer is simply that the former is used for "untyped"
memory access, and the later is used for "typed" memory access. Let's refer to
these as "raw pointers" and "typed pointers". Because operations on raw pointers
access untyped memory, the compiler cannot make assumptions about the underlying
type of memory and must be conservative. With operations on typed pointers, the
compiler may make strict assumptions about the type of the underlying memory,
which allows more aggressive optimization.
Memory can only be accessed by a typed pointer when it is currently
bound to the Pointee type. Memory can be bound to type
Tvia:UnsafePointer<T>.allocate(capacity: n)UnsafePointer<Pointee>.withMemoryRebound(to: T.self, capacity: n) {...}UnsafeMutableRawPointer.initializeMemory(as: T.self, at: i, count: n, to: x)UnsafeMutableRawPointer.initializeMemory(as: T.self, from: p, count: n)UnsafeMutableRawPointer.moveInitializeMemory(as: T.self, from: p, count: n)UnsafeMutableRawPointer.bindMemory(to: T.self, capacity: n)Mangle UnsafeRawPointer as predefined substitution 'Sv' for Swift void
pointer ([urp] are taken).