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
[Serialization] Handle XREFs to private types #14352
Conversation
@gottesmm, @atrick, in case you're curious. This level of "fix" isn't that intrusive, but… @slavapestov is going to hate this. @swift-ci Please test |
@DougGregor review ping (since it is a 4.1 regression of sorts) |
e94b933
to
841c27a
Compare
@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.
It looks sound, and I don't see any better way to do this... yeah... LGTM
XRefTypePathPieceLayout::readRecord(scratch, IID, privateDiscriminator, | ||
onlyInNominal); | ||
if (privateDiscriminator) | ||
goto giveUpFastPath; |
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.
Boo :(
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 guess I could have written a do-while-false loop, but I think that would have been less self-documenting.
We can encounter these when the compiler modifies an inlinable function to break apart a struct and the struct uses a private type for one of its fields. It's questionable whether we /should/ handle this, but meanwhile this /is/ a non-intrusive fix that preserves the performance of non-resilient libraries. (That is, it appears this worked in Swift 4.0, though perhaps not all of the same optimizations kicked in.) https://bugs.swift.org/browse/SR-6874
841c27a
to
b9d3c6e
Compare
@swift-ci Please smoke test |
We can encounter these when the compiler modifies an inlinable function to break apart a struct and the struct uses a private type for one of its fields. It's questionable whether we /should/ handle this, but meanwhile this /is/ a non-intrusive fix that preserves the performance of non-resilient libraries. (That is, it appears this worked in Swift 4.0, though perhaps not all of the same optimizations kicked in.) https://bugs.swift.org/browse/SR-6874 (cherry picked from commit af67204)
We can encounter these when the compiler modifies an inlinable function to break apart a struct and the struct uses a private type for one of its fields. It's questionable whether we /should/ handle this, but meanwhile this /is/ a non-intrusive fix that preserves the performance of non-resilient libraries. (That is, it appears this worked in Swift 4.0, though perhaps not all of the same optimizations kicked in.) https://bugs.swift.org/browse/SR-6874 (cherry picked from commit af67204)
We can encounter these when the compiler modifies an inlinable function to break apart a struct and the struct uses a private type for one of its fields. It's questionable whether we should handle this, but meanwhile this is a non-intrusive fix that preserves the performance of non-resilient libraries.
(That is, it appears this worked in Swift 4.0, though perhaps not all of the same optimizations kicked in.)
SR-6874 / rdar://problem/37072260