Skip to content
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

Merged

Conversation

harlanhaskins
Copy link
Contributor

@harlanhaskins harlanhaskins commented Feb 4, 2019

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

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.
@harlanhaskins harlanhaskins force-pushed the cache-rules-everything-around-me branch from e9d5cd2 to 6ae20a9 Compare February 4, 2019 22:40
@@ -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.
Copy link
Contributor

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?

Copy link
Contributor Author

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());
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.
@harlanhaskins
Copy link
Contributor Author

@swift-ci please test

@harlanhaskins harlanhaskins merged commit 5763016 into swiftlang:master Feb 5, 2019
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.

3 participants