swift-system
swift-system copied to clipboard
apple
Update package with changes from recent ABI stable releases
This brings the contents of this package up to date with versions of the ABI stable System module that shipped in recent iOS/macOS releases.
Most changes only touch internal implementation details, but some ABI-related fixes also affect the public API. There are no source-incompatible changes.
- ABI stability fixes (un-deprecate
CModeT, don't usePlatformCharin inlinable contexts that need to deploy to iOS 14) - New utilities:
_RawBuffer,Array<String>._withCStringArray,_withOptionalUnsafePointerOrNull,_withStackBuffer,system_memset - Prefer using explicit optionals to implicitly-unwrapped ones
- Add support for wildcard matching in mocking tests
- A bunch of new availability annotations. (I expect there will be more of these coming in future PRs.)
19:27:49
/home/buildnode/jenkins/workspace/pr-swift-system-linux/branch-main/swift-system/Sources/System/Internals/Exports.swift:90:17: error: value of optional type 'UnsafeMutableRawPointer?' must be unwrapped to a value of type 'UnsafeMutableRawPointer'
19:27:49 memset(buffer.baseAddress, CInt(byte), buffer.count)
19:27:49 ^
19:27:49 /home/buildnode/jenkins/workspace/pr-swift-system-linux/branch-main/swift-system/Sources/System/Internals/Exports.swift:90:17: note: coalesce using '??' to provide a default when the optional value contains 'nil'
19:27:49 memset(buffer.baseAddress, CInt(byte), buffer.count)
19:27:49 ^
19:27:49 ?? <#default value#>
19:27:49 /home/buildnode/jenkins/workspace/pr-swift-system-linux/branch-main/swift-system/Sources/System/Internals/Exports.swift:90:17: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
19:27:49 memset(buffer.baseAddress, CInt(byte), buffer.count)
19:27:49 ^
19:27:49 !
Ah, memset must have a different signature on Linux.
I can try to build this on windows tomorrow, or even better if you can test it on windows 😀
Yeah, this breaks the Windows build in several ways. 😖
I don't quite get why we don't just wrap HANDLE on Windows -- is there a point in exposing these almost-but-not-quite-POSIX APIs? Assuming there is one, it would probably make more sense to spin them off into their own set of source files, isolated from actual POSIX OSes.
Wrapping HANDLE won't do anything; it is an opaque pointer that can represent anything and has different handling in different cases (i.e. you really want it to be an optional pointer that can be NULL, -1, a valid pointer, or a numeric value). So, having that not be wrapped is rather convenient when interfacing with most calls.
We could still have a type that makes it explicit what's happening and allows more convenient construction (sort of like OpaquePointer, but also covering the numerical cases). (Given that I expect that the Windows port is still largely unconstrained by source compatibility burdens, it should also be possible to tweak the Clang Importer to translate HANDLE types automatically.)
Or, if that proves impractical for whatever reason, we could just wrap the associated entry points as top-level functions taking OpaquePointer or UMRP or whatever HANDLE happens to be imported as.
Having an FileDescriptor type with .open or .pread methods that look just like POSIX syscalls but map to something completely different does not seem very useful to me. Swift System ought to expose the underlying sytem abstractions as faithfully as possible; it should not engage in, say, translating Windows Error Codes into errno values.
(Despite the wonderful FilePath type (which I hope we can move to/near the stdlib at some point), I don't consider Swift System to be the right place for cross-platform abstractions or emulation layers.)
Having the Windows file APIs share the same code paths / entry points as their Un*x counterparts seems especially counterproductive to me -- it's a maintenance burden we don't need.