[SE-0456, -0467] Data+Span+MutableSpan #1276
Conversation
|
@swift-ci please test |
|
@swift-ci please test |
|
The Windows test https://ci-external.swift.org/job/swift-foundation-pull-request-windows/717/ ran with |
|
@swift-ci please test macOS platform |
|
@swift-ci please test macOS platform |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test |
| buffer = UnsafeRawBufferPointer(start: nil, count: 0) | ||
| case .inline: | ||
| buffer = unsafe UnsafeRawBufferPointer( | ||
| start: UnsafeRawPointer(Builtin.addressOfBorrow(self)), |
There was a problem hiding this comment.
Are we opening the door here for Foundation to use the Builtin module generally? Or is this a placeholder for some stdlib API/SPI cover that's coming down the road?
There was a problem hiding this comment.
The issue with the Builtin module is one of source stability, and as a result we don't want to rely on it in any module not built with the compiler, including Foundation. We can probably replace this with something from the stdlib level: we may be able to model it as a particular Span initializer from which we'd extract the information we need. This is not available but it should be doable now.
| @@ -9,7 +9,8 @@ import CompilerPluginSupport | |||
| let availabilityTags: [_Availability] = [ | |||
| _Availability("FoundationPreview"), // Default FoundationPreview availability, | |||
| _Availability("FoundationPredicate"), // Predicate relies on pack parameter runtime support | |||
| _Availability("FoundationPredicateRegex") // Predicate regexes rely on new stdlib APIs | |||
| _Availability("FoundationPredicateRegex"), // Predicate regexes rely on new stdlib APIs | |||
| _Availability("FoundationSpan", availability: .future), // Availability of Span types | |||
There was a problem hiding this comment.
Does the // swift-tools-version: 5.9 above need to be changed?
There was a problem hiding this comment.
We could choose to change that to 6.0, or maybe 6.1, if we wanted but we don't want to make this 6.2 yet so I think it's best to keep it as-is. The tools version is not the same as the compiler version for Xcode/Darwin as the tools version is strictly equivalent to what tools are packaged in Xcode when you build the package in Xcode (and not the tools in your selected toolchain). There isn't yet an Xcode that ships with 6.2 tools, so to support building this project with older Xcodes (even with a downloaded 6.2 OSS toolchain) we'd want to support a lower tools version.
There was a problem hiding this comment.
I was thinking of doing that in a follow-up PR
|
The Windows CI failure is due to swiftlang/swift#81471. |
Add the properties
span,mutableSpan,bytesandmutableBytestoData, as proposed in SE-0456 and SE-0467.Addresses rdar://137711067