Skip to content

[Serialization] Restrict loading swiftmodule files to the SDK that built them #37768

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 3 commits into from
Sep 14, 2021

Conversation

xymus
Copy link
Contributor

@xymus xymus commented Jun 3, 2021

Serialize the SDK canonical name used to build swiftmodule files and use it at deserialization to ensure that a swiftmodule file is loaded only with the same SDK used to build it.

This will report unsupported configurations like:

  • Installing roots between incompatible SDKs without deleting the swiftmodule files.
  • Having multiple targets in the same project using different SDKs.
  • Loading a swiftmodule created with a newer SDK (and stdlib) with an older SDK.

All of these configurations lead to hard to investigate deserialization failures and should be reported early by this new check, before reaching a deserialization failure.

rdar://78048939

@xymus xymus requested review from bnbarham and nkcsgexi June 3, 2021 18:24
@xymus
Copy link
Contributor Author

xymus commented Jun 3, 2021

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Jun 3, 2021

@swift-ci Please test Apple Silicon

Copy link
Contributor

@bnbarham bnbarham left a comment

Choose a reason for hiding this comment

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

LGTM - this is awesome!

Serialize the canonical name of the SDK used when building a swiftmodule
file and use it to ensure that the swiftmodule file is loaded only with
the same SDK. The SDK name must be passed down from the frontend.

This will report unsupported configurations like:

- Installing roots between incompatible SDKs without deleting the
swiftmodule files.
- Having multiple targets in the same project using different SDKs.
- Loading a swiftmodule created with a newer SDK (and stdlib) with an
older SDK.

All of these lead to hard to investigate deserialization failures and
this change should detect them early, before reaching a deserialization
failure.

rdar://78048939
Tests using a mock SDK can't load the stdlib of the normal SDK (or the
just-built one) with the recent changes. Use `-parse-stdlib` in those
tests to prevent loading the stdlib implicitly.
…t SDK

The API digester forces loading the stdlib which may pick up an stdlib
from a different SDK than the one being tested. Disable the check
enforcing loading only swiftmodules built for the same SDK.
@xymus
Copy link
Contributor Author

xymus commented Sep 13, 2021

The logic to get the SDK name in the frontend wasn't reliable. Trying a different approach where the driver passes the name down instead.

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Sep 14, 2021

@swift-ci Please smoke test macOS

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