-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[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
Conversation
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.
@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()); |
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.
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
?
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.
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.
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.
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.
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.
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
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