-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Some const { }
asserts for #128200
#128465
Conversation
r? estebank |
rustc_errors: use perfect hashing for character replacements The correctness of code in rust-lang#128200 relies on an array being sorted (so that it can be used in binary search later), which is currently enforced with `// tidy-alphabetical` (and characters being written in `\u{XXXX}` form), as well as lack of duplicate entries with conflicting keys, which is not currently enforced. A const assert or a test can be added checking that (implemented in rust-lang#128465). But this PR tries to use [perfect hashing](https://en.wikipedia.org/wiki/Perfect_hash_function) instead. The performance implications are unclear. Asymptotically it's faster, but in reality we should just benchmark. Plus if there are no significant performance wins, this entire things is probably not even worse the additional dependencies it brings. UPD: funnily enough, there's a PR optimizing the binary search implementation (rust-lang#128254) in the queue right now. So I guess we have to wait until that is merged too before benchmarking this.
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.
r=me, wither with the additional check or not
"The OUTPUT_REPLACEMENTS array must be sorted (for binary search to work) \ | ||
and must contain no duplicate entries" |
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.
Should we add another check for assert_neq!(OUTPUT_REPLACEMENTS[i - 1].0, OUTPUT_REPLACEMENTS[i].0)
too?
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 check is already <
and not <=
@bors r+ |
Some `const { }` asserts for rust-lang#128200 The correctness of code in rust-lang#128200 relies on an array being sorted (so that it can be used in binary search later), which is currently enforced with `// tidy-alphabetical` (and characters being written in `\u{XXXX}` form), as well as lack of duplicate entries with conflicting keys, which is not currently enforced. This PR changes it to using a `const{ }` assertion (and also checks for duplicate entries). Sadly, we cannot use the recently-stabilized `is_sorted_by_key` here, because it is not const (but it would not allow us to check for uniqueness anyways). Instead, let's write a manual loop. Alternative approach (perfect hash function): rust-lang#128463 r? `@ghost`
…iaskrgr Rollup of 2 pull requests Successful merges: - rust-lang#128465 (Some `const { }` asserts for rust-lang#128200 ) - rust-lang#128795 (Update E0517 message to reflect RFC 2195.) r? `@ghost` `@rustbot` modify labels: rollup
☀️ Test successful - checks-actions |
Finished benchmarking commit (d3a3939): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -0.1%, secondary -0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 762.874s -> 760.03s (-0.37%) |
The correctness of code in #128200 relies on an array being sorted (so that it can be used in binary search later), which is currently enforced with
// tidy-alphabetical
(and characters being written in\u{XXXX}
form), as well as lack of duplicate entries with conflicting keys, which is not currently enforced.This PR changes it to using a
const{ }
assertion (and also checks for duplicate entries). Sadly, we cannot use the recently-stabilizedis_sorted_by_key
here, because it is not const (but it would not allow us to check for uniqueness anyways). Instead, let's write a manual loop.Alternative approach (perfect hash function): #128463
r? @ghost