Forward Hash::write_iN to Hash::write_uN#73800
Merged
bors merged 1 commit intorust-lang:masterfrom Jun 28, 2020
Merged
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
Hasher::write_iN()methods should forward toHasher::write_uN(), because some Hasher implementations implement only thewrite_uN()variants, with the expectation thatwrite_iN()will use the same implementation. Most notably, this is the case for the FxHasher used by rustc itself.This used to be the case previously, but was broken in #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 #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.