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

Hasher: replace unsafe trasmute with to_ne_bytes #59982

Merged
merged 1 commit into from
Apr 15, 2019

Conversation

stepancheg
Copy link
Contributor

Spead the knowledge of to_ne_bytes functions existence.

Spead the knowledge of `to_ne_bytes` functions existence.
@rust-highfive
Copy link
Collaborator

r? @rkruppe

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 15, 2019
@hanna-kruppe
Copy link
Contributor

Thanks!

@bors r+

@bors
Copy link
Contributor

bors commented Apr 15, 2019

📌 Commit fd4ac0e has been approved by rkruppe

@bors bors 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 Apr 15, 2019
@bors
Copy link
Contributor

bors commented Apr 15, 2019

⌛ Testing commit fd4ac0e with merge a55f6be...

bors added a commit that referenced this pull request Apr 15, 2019
Hasher: replace unsafe trasmute with to_ne_bytes

Spead the knowledge of `to_ne_bytes` functions existence.
@bors
Copy link
Contributor

bors commented Apr 15, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: rkruppe
Pushing a55f6be to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 15, 2019
@bors bors merged commit fd4ac0e into rust-lang:master Apr 15, 2019
@bors bors mentioned this pull request Apr 15, 2019
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 28, 2020
Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 28, 2020
Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 28, 2020
Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.

4 participants