Skip to content

[ClangImporter] Put the Swift compiler version into the module hash #17344

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 1 commit into from
Jun 21, 2018

Conversation

jrose-apple
Copy link
Contributor

@jrose-apple jrose-apple commented Jun 20, 2018

This is overkill when we could just be better about updating the lookup table version, but it's hard to remember to do that when changing something in ImportName.cpp or whatever.

rdar://problem/41262526

This is overkill when we could just be better about updating the
lookup table version, but it's hard to remember to do that when
changing something in ImportName.cpp or whatever.
@jrose-apple
Copy link
Contributor Author

@swift-ci Please smoke test

@@ -1606,7 +1606,8 @@ SwiftNameLookupExtension::hashExtension(llvm::hash_code code) const {
return llvm::hash_combine(code, StringRef("swift.lookup"),
SWIFT_LOOKUP_TABLE_VERSION_MAJOR,
SWIFT_LOOKUP_TABLE_VERSION_MINOR,
inferImportAsMember);
inferImportAsMember,
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.

I would have expected this to match what we add to metadata.UserInfo above - should this use swiftCtx.LangOpts.EffectiveLanguageVersion or maybe the user info should remove it? Apropos, should there be a test that checks that output using clang -module-file-info?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The effective language version already makes its way into the hash via API notes, but if you think it's simpler to just have them do the same thing I can change it. I don't see how I can write a test for the hash changing, though, since this one's about what happens if you change how the compiler is built.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ahh, now I see that setting the effective version just makes it print a superset of the version information, not different information. Nevermind, it's fine as-is.

I don't see how I can write a test for the hash changing

I agree, you can't really test the hashing. I was thinking it would be nice to test what we're printing with clang -module-file-info for the extension, since the principle is that anything affecting the hash should get printed there. But that's not something you need to do for this patch, sorry for not making that clear.

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

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

This is very, very, very conservative... but it'll prevent crashes and we aren't getting much in the way of module re-use anyway. LGTM

@jrose-apple jrose-apple merged commit 26325e8 into swiftlang:master Jun 21, 2018
@jrose-apple jrose-apple deleted the hashtag branch June 21, 2018 18:40
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