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

Use 128 bit instead of Symbol for crate disambiguator #45476

Merged
merged 2 commits into from
Oct 25, 2017

Conversation

Xanewok
Copy link
Member

@Xanewok Xanewok commented Oct 23, 2017

As discussed on gitter, this changes crate_disambiguator from Strings to what they are represented as, a 128 bit number.

There's also one bit I think also needs to change, but wasn't 100% sure how: create_root_def. Should I change DefKey::root_parent_stable_hash to accept Fingerprint as crate_disambiguator to quickly combine the hash of crate_name with the new 128 bit hash instead of a string for a disambiguator?

r? @michaelwoerister

EDIT: Are those 3 tests mir-opt failing, because the hash is different, because we calculate it a little bit differently (storing directly instead of hashing the hex-string representation)? Should it be updated like in #45319?

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @michaelwoerister (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

let crate_name = format!("{}-{}",
crate_name,
base_n::encode(hasher.finish(), INT_ENCODE_BASE));
base_n::encode(crate_disambiguator, INT_ENCODE_BASE));
Copy link
Member Author

Choose a reason for hiding this comment

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

This truncates the hash to 64 bits, should I implement a 128 but encoding in base_n?

Copy link
Contributor

Choose a reason for hiding this comment

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

This is pre-existing?

Copy link
Member Author

Choose a reason for hiding this comment

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

Now sure what you mean exactly, but to_smaller_hash() already exists and truncates to 64 bits.
I meant to ask if base_n::encode should be extended to work with Fingerprint/u128, in addition to u64. To be honest, I saw that it accepts u64, so thought that truncating 128->64 might be acceptable in this case

Copy link
Member

Choose a reason for hiding this comment

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

The code you wrote should have roughly the same effect as before since DefaultHasher also produces 64 bits. We don't want these hashes to be too long because they end up in directory names and long paths/names sometimes cause trouble for various reasons (file system support, operating system API restrictions, etc).

Maybe you could add a comment here, similar to the one that is replaced:

// The full crate disambiguator is really long. 64 bits of it should be
// sufficient.

@kennytm kennytm added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 24, 2017
Copy link
Member

@michaelwoerister michaelwoerister left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, @Xanewok! It already looks pretty good.

Browsing through the code though, I think it is a good idea to introduce a new type for the disambiguator, as in:

#[derive(Copy, Clone, Hash, Debug, ...)]
pub struct CrateDisambiguator {
    fingerprint: Fingerprint
}

impl CrateDisambiguator {
    pub fn to_fingerprint(self) -> Fingerprint {
        self.fingerprint
    }
}

You could put that into librustc/session/config.rs for example. It seems slightly cleaner to me if the disambiguator as its own type.

Regarding the mir-opt tests, yes, just update the hash values.

@@ -118,7 +119,7 @@ impl<'a, 'hir> NodeCollector<'a, 'hir> {
}

pub(super) fn finalize_and_compute_crate_hash(self,
crate_disambiguator: &str)
crate_disambiguator: &Fingerprint)
Copy link
Member

Choose a reason for hiding this comment

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

Usually we pass around Fingerprint by value. It implements Copy so that should be easy.

let crate_name = format!("{}-{}",
crate_name,
base_n::encode(hasher.finish(), INT_ENCODE_BASE));
base_n::encode(crate_disambiguator, INT_ENCODE_BASE));
Copy link
Member

Choose a reason for hiding this comment

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

The code you wrote should have roughly the same effect as before since DefaultHasher also produces 64 bits. We don't want these hashes to be too long because they end up in directory names and long paths/names sometimes cause trouble for various reasons (file system support, operating system API restrictions, etc).

Maybe you could add a comment here, similar to the one that is replaced:

// The full crate disambiguator is really long. 64 bits of it should be
// sufficient.

@michaelwoerister
Copy link
Member

There's also one bit I think also needs to change, but wasn't 100% sure how: create_root_def. Should I change DefKey::root_parent_stable_hash to accept Fingerprint as crate_disambiguator to quickly combine the hash of crate_name with the new 128 bit hash instead of a string for a disambiguator?

Yes, you can do that. It would be a bit more consistent this way.

@Xanewok
Copy link
Member Author

Xanewok commented Oct 24, 2017

@michaelwoerister created a CrateDisambiguator newtype (awfully similar to DefPathHash) in session/mod.rs. config.rs had a lot of CLI/config-related data and logic and it somehow felt better to put this small type directly inside mod.rs, especially since it's used in Session - hope that's okay.
Addressed comments and fixed tests 🚀

@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 24, 2017
@michaelwoerister
Copy link
Member

Excellent, thanks a lot @Xanewok!

@bors r+

@bors
Copy link
Contributor

bors commented Oct 25, 2017

📌 Commit 7fa64bc has been approved by michaelwoerister

@michaelwoerister michaelwoerister added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 25, 2017
@bors
Copy link
Contributor

bors commented Oct 25, 2017

⌛ Testing commit 7fa64bc with merge f764eaf...

bors added a commit that referenced this pull request Oct 25, 2017
…erister

Use 128 bit instead of Symbol for crate disambiguator

As discussed on gitter, this changes `crate_disambiguator` from Strings to what they are represented as, a 128 bit number.

There's also one bit I think also needs to change, but wasn't 100% sure how: [create_root_def](https://github.com/rust-lang/rust/blob/f338dba29705e144bad8b2a675284538dd514896/src/librustc/hir/map/definitions.rs#L468-L482). Should I change `DefKey::root_parent_stable_hash` to accept `Fingerprint` as crate_disambiguator to quickly combine the hash of `crate_name` with the new 128 bit hash instead of a string for a disambiguator?

r? @michaelwoerister

EDIT: Are those 3 tests `mir-opt` failing, because the hash is different, because we calculate it a little bit differently (storing directly instead of hashing the hex-string representation)? Should it be updated like in #45319?
@bors
Copy link
Contributor

bors commented Oct 25, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing f764eaf to master...

@michaelwoerister
Copy link
Member

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants