-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[stdlib] Update Codable.swift (NFC) #63184
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
Conversation
https://ci.swift.org/job/swift-PR-macos-smoke-test/5161/ dyld: Symbol not found:
swift demangle:
UPDATE: The "dyld: Symbol not found" error was because: mutating func encode(
contentsOf sequence: some Sequence<some Encodable>
) throws uses two generic parameters: mutating func encode<T, U>(
contentsOf sequence: T
) throws where T: Sequence, U: Encodable, T.Element == U |
https://ci.swift.org/job/swift-PR-macos-smoke-test/5166/
UPDATE: rdar://99932758 (via #61088). |
cc: @natecook1000 |
https://ci.swift.org/job/swift-PR-macos-smoke-test/5170/
Using Opaque parameters in other APIs were removed (in |
Some of these are kind of surprising (but my trust in the API digester is... not high)
This seems like it should be a totally standard change to be able to make safely — is it because
🧐 The changes that succeeded look good to me! 👍🏻 |
@natecook1000 Thanks for taking a look. My assumption is that the opaque parameters were valid, but API Digester doesn't understand them yet. (rdar://99932758 might have more details?) |
It does look like rdar://99932758, which is blocking #61088. There has been no additional information since #61088. These changes are clearly source-compatible. The strange behaviour of the API digester suggests not trusting it, and manually checking the generated library before and after this for changes in the list of mangled symbols. |
@glessard Thanks. Do you think this pull request can be merged? I can move the rejected changes to a draft PR. |
If we're sure it doesn't change the symbol list, then I would approve -- I haven't checked, and I would like to know whether anyone has. (I don't yet trust the automated tests surrounding these changes.) Moving the rejected changes to another PR would be a good thing. |
@benrimmington I've "manually" checked the list of symbols, and I'm happy with what I see (i.e. the list does not change before and after this change.) Given that, I'd be happy to merge. |
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.
Thanks for putting in the effort to convert this to the newer syntax!
@glessard Thanks for checking the symbols. I re-examined the build log of the first attempt, which included
I'm inclined to believe that api-digester has checked the mangled names. However, the macos.json baselines haven't been updated for 3 years, so they won't include the |
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.
Lovely work! The danger of subtle ABI breaks is a bit higher than usual here, but if the exported symbol names match before/after this change, then we're probably fine.
(False positives in the ABI checker need to be reported to source analysis team, and added to the no-asserts allow list.)
stdlib/public/core/Codable.swift
Outdated
@available(SwiftStdlib 5.6, *) | ||
public init?<T: CodingKey>(codingKey: T) { | ||
public init?(codingKey: some CodingKey) { |
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.
Be careful with this one (and the two others of the same sort below) -- the constraints are weirdly split across the extension and the member, and rewriting them could easily end up causing a subtle ABI issue. This is exploring new language territory, and the ABI checker is unlikely to be of any help (other than flagging this as a potential break), but if the exported symbols match before/after this change, then we may be okay.
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.
I'm inclined to believe that api-digester has checked the mangled names.
I'm not inclined to believe that. I don't think I've seen a list of symbols that libswiftCore is expected to export anywhere in this repository.
However, the macos.json baselines haven't been updated for 3 years, so they won't include the CodingKeyRepresentable protocol.
D'oh. OK, so the ABI checker results are irrelevant, and we need to do manual checks.
Cc @nkcsgexi
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.
I've deferred the false positives and CodingKeyRepresentable
changes to another pull request.
@swift-ci Please smoke test |
any
keyword.