[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. |
|
swiftlang/swift#81816 should fix the macOS CI problem. |
glessard
force-pushed
the
data+span
branch
3 times, most recently
from
49f2159 to
161f318
Compare
|
@swift-ci please test linux platform |
The current Windows nightly is too old to be able to compile the expected syntax.
|
@swift-ci please test Linux platform |
|
@swift-ci please test Windows platform |
|
@swift-ci please test |
|
@swift-ci please test macOS platform |
|
@swift-ci please test Linux platform |
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
|
@swift-ci please test macOS platform |
|
@swift-ci please test |
|
The macOS test failure is due to the test binary trying to link |
|
@swift-ci please test |
* [SE-0456, -0467] Data+Span+MutableSpan * Document compiler issue * fix use of non-public initializers * Address availability and compiler versions * adjust cmake configuration * temporarily disable Span and MutableSpan for Windows The current Windows nightly is too old to be able to compile the expected syntax. * update linux build flags * shield lifetime-dependence syntax * shield new types from testing module * compile out MutableSpan mutations when unsupported by deployment target
Add the properties
span,mutableSpan,bytesandmutableBytestoData, as proposed in SE-0456 and SE-0467.Addresses rdar://137711067