-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SE-0163] Migrate from deprecated Unicode APIs (part 3) #33175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SE-0163] Migrate from deprecated Unicode APIs (part 3) #33175
Conversation
var buffer: UInt64 = 0 | ||
var i = 0 | ||
let sink: (UInt8) -> Void = { | ||
#if _endian(little) | ||
buffer = buffer | (UInt64($0) << (UInt64(i) * 8)) | ||
#else | ||
buffer = buffer | (UInt64($0) << (UInt64(7-i) * 8)) | ||
#endif | ||
i += 1 | ||
} | ||
UTF8.encode(unicodeScalar, into: sink) | ||
return body(UnsafeBufferPointer( | ||
start: UnsafePointer(Builtin.addressof(&buffer)), | ||
count: i)) | ||
return unicodeScalar.withUTF8CodeUnits { body($0) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is using the internal Unicode.Scalar.withUTF8CodeUnits(_:)
method, which has been ABI-public since Swift 5.0 — I assume it will also be available in the bundled stdlib (e.g. when targeting macOS 10.9).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, those were built from the same sources!
(It's unfortunate that this non-public entry point is missing its leading underscore.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(There was also a fix in Swift 5.1 for big-endian platforms.)
// CHECK: @"$ss12StaticStringV14withUTF8BufferyxxSRys5UInt8VGXElFyAEcfU_" | ||
// CHECK: @"$ss12StaticStringV14withUTF8BufferyxxSRys5UInt8VGXElFxAFXEfU_" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test now has a different closure #1
type in its mangled name.
-
Old swift-demangle result:
$ss12StaticStringV14withUTF8BufferyxxSRys5UInt8VGXElFyAEcfU_ ---> closure #1 (Swift.UInt8) -> () in Swift.StaticString.withUTF8Buffer<A>((Swift.UnsafeBufferPointer<Swift.UInt8>) -> A) -> A
-
New swift-demangle result:
$ss12StaticStringV14withUTF8BufferyxxSRys5UInt8VGXElFxAFXEfU_ ---> closure #1 (Swift.UnsafeBufferPointer<Swift.UInt8>) -> A in Swift.StaticString.withUTF8Buffer<A>((Swift.UnsafeBufferPointer<Swift.UInt8>) -> A) -> A
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! 👍 (Cc @milseman, too)
var buffer: UInt64 = 0 | ||
var i = 0 | ||
let sink: (UInt8) -> Void = { | ||
#if _endian(little) | ||
buffer = buffer | (UInt64($0) << (UInt64(i) * 8)) | ||
#else | ||
buffer = buffer | (UInt64($0) << (UInt64(7-i) * 8)) | ||
#endif | ||
i += 1 | ||
} | ||
UTF8.encode(unicodeScalar, into: sink) | ||
return body(UnsafeBufferPointer( | ||
start: UnsafePointer(Builtin.addressof(&buffer)), | ||
count: i)) | ||
return unicodeScalar.withUTF8CodeUnits { body($0) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, those were built from the same sources!
(It's unfortunate that this non-public entry point is missing its leading underscore.)
@swift-ci benchmark |
Performance: -O
Code size: -OPerformance: -Osize
Code size: -OsizePerformance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview
|
LGTM |
Follow-up to: #32920