-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
[ParseableInterfaces] Refine cache keys and dependency checks #22357
[ParseableInterfaces] Refine cache keys and dependency checks #22357
Conversation
Hashing the contents of the interface files is overkill. In practice, size and last modification time are enough to determine if a file has changed on disk, and therefore should be rebuilt.
These tests made sure that changing the hash, while keeping mtime constant, causes dependent modules to be rebuilt. Flip this around so changing the mtime, while keeping the hash constant, causes the same rebuilding behavior.
Previously, we included the PCH hash components in the cache key. While they didn’t do any harm, they didn’t contribute any unique information about the module in question. Additionally, passing the effective language version in means that each dependency that uses a different -swift-version would re-compile all of its dependencies. This is unfortunate, as that means the standard library is recompiled potentially several times.
e9d5cd2
to
6ae20a9
Compare
@@ -27,12 +27,11 @@ | |||
// RUN: %{python} %S/Inputs/make-old.py %t/modulecache/OtherModule-*.swiftmodule | |||
// | |||
// | |||
// Actual test: Change a byte in OtherModule.swiftinterface, check we only rebuild its cached module. | |||
// Actual test: Change the mtime of OtherModule.swiftinterface, check we only rebuild its cached module. |
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.
Are there already tests for changing the size but keeping the mtime constant?
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, for both the leaf and intermediate modules.
// Explicitly don't pass in the "effective" language version -- this would | ||
// mean modules built in different -swift-version modes would rebuild their | ||
// dependencies. | ||
llvm::hash_code H = hash_value(swift::version::getSwiftFullVersion()); |
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.
Can you add a test that this doesn't happen anymore?
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.
Ah! Yes, thanks for the reminder.
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.
Added the test. Fails with an older build, succeeds with this one.
Adds a test to make sure that there's only one version of a dependent module, regardless how many -swift-versions are present in the dependency hierarchy.
@swift-ci please test |
Hashing the contents of the interface files for dependency checking is overkill. In practice, size and last modification time are enough to determine if a file has changed on disk, and therefore should be rebuilt.
As for cache keys, previously, we included the PCH hash components in the cache key. While they didn’t do any harm, they didn’t contribute any unique information about the module in question.
Additionally, passing the effective language version in means that each dependency that uses a different -swift-version would re-compile all of its dependencies. This is unfortunate, as that means the standard library is recompiled potentially several times.
rdar://46503065