Add a dedicated length-prefixing method to Hasher by scottmcm · Pull Request #94598 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Relevant to the compiler team, which will review and decide on the PR/issue.
label
Relevant to the library API team, which will review and decide on the PR/issue.
label
Relevant to the compiler team, which will review and decide on the PR/issue.
label
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
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
compiler-errors added a commit to compiler-errors/rust that referenced this pull request
…errors
Put the incompatible_closure_captures lint messages in alphabetical order
Looks like they were in hash order before, which was causing me trouble in rust-lang#94598, so this PR sorts the errors by trait name.
This accomplishes two main goals:
- Make it clear who is responsible for prefix-freedom, including how they should do it
- Make it feasible for a
Hasherthat doesn't care about Hash-DoS resistance to get better performance by not hashing lengths
This does not change rustc-hash, since that's in an external crate, but that could potentially use it in future.
We might want to change the default before stabilizing (or maybe even after), but for getting in the new unstable methods, leave it as-is for now. That way it won't break cargo and such.
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
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
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request
…errors
Put the incompatible_closure_captures lint messages in alphabetical order
Looks like they were in hash order before, which was causing me trouble in rust-lang#94598, so this PR sorts the errors by trait name.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request
…errors
Put the incompatible_closure_captures lint messages in alphabetical order
Looks like they were in hash order before, which was causing me trouble in rust-lang#94598, so this PR sorts the errors by trait name.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request
…errors
Put the incompatible_closure_captures lint messages in alphabetical order
Looks like they were in hash order before, which was causing me trouble in rust-lang#94598, so this PR sorts the errors by trait name.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…anieu
Further elaborate the lack of guarantees from Hasher
I realized that I got too excited in rust-lang#94598 by adding new methods, and forgot to do the documentation to really answer the core question in rust-lang#94026.
This PR just has that doc update.
r? @Amanieu
