Skip to content

Serialization: Stop reading control block early on version mismatch and fix current control block ordering #73828

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

Merged
merged 4 commits into from
Jun 5, 2024

Conversation

xymus
Copy link
Contributor

@xymus xymus commented May 22, 2024

Reorder components of the control block to support reading the control blocks of swiftmodules from mismatching compilers.

Also harden the compiler to this kind of issues by giving up early on the control block validation if the format version doesn’t match. This will protect both against mistakes like this and differences between compiler branches.

rdar://128551774

@xymus xymus requested a review from drodriguez May 22, 2024 21:53
@xymus
Copy link
Contributor Author

xymus commented May 22, 2024

@swift-ci Please smoke test

Comment on lines +337 to +342

// If the format version doesn't match, give up after also getting the
// compiler version. This provides better diagnostics.
if (result.status != Status::Valid)
return result;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said in the other PR, not sure about how any of this work, I just want to understand the consequences of this change. Wouldn't this make working with a compiler from main impossible to use against files compiled with previous compilers? That would make using .swiftmodule files distributed by Xcode not valid, wouldn't it? Before this I think old files were still mostly compatible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't change the current behavior. I would not expect a main compiler to be able to use swiftmodules built by any compiler older than a week or so. If that swiftmodule has a different serialization format it would have been rejected already.

The main content of swiftmodule files have very limited compatibility as they are designed to be a local cache. In theory they should only be read by the exact same compiler that wrote them, and in the exact same context. That's why any distributed modules should use swiftinterfaces. And the only swiftmodules shipped with Xcode are only the prebuilt cache, they can all be rebuilt from swiftinterfaces in a similar manner by newer compilers.

So any swiftmodule with a different serialization format version are rejected. swiftmodule files are also rejected between released compilers with a different tag. We leave some room for dev compilers, just to avoid rebuilding the stdlib all the time during development.

As you pointed out, the control block should be compatible with different compilers. But as soon as we know it should be rejected it's safe to skip reading the rest of the information.

@xymus
Copy link
Contributor Author

xymus commented Jun 5, 2024

@swift-ci Please smoke test

@xymus xymus merged commit 80fc3e2 into swiftlang:main Jun 5, 2024
3 checks passed
@xymus xymus deleted the serial-fix-control-block branch June 5, 2024 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants