-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
BTreeMap: test invariants more thoroughly and more readably #77612
Conversation
a764275
to
f4034eb
Compare
@bors r+ rollup |
📌 Commit f4034eb has been approved by |
…ulacrum BTreeMap: test invariants more thoroughly and more readably r? @Mark-Simulacrum
…ulacrum BTreeMap: test invariants more thoroughly and more readably r? @Mark-Simulacrum
…ulacrum BTreeMap: make PartialCmp/PartialEq explicit and tested Follow-up on a topic raised in rust-lang#77612 r? @Mark-Simulacrum
☔ The latest upstream changes (presumably #78001) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
f4034eb
to
503c946
Compare
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
503c946
to
488b999
Compare
@bors r+ rollup |
📌 Commit 488b999 has been approved by |
Rollup of 10 pull requests Successful merges: - rust-lang#77612 (BTreeMap: test invariants more thoroughly and more readably) - rust-lang#77761 (Assert that pthread mutex initialization succeeded) - rust-lang#77778 ([x.py setup] Allow setting up git hooks from other worktrees) - rust-lang#77838 (const keyword: brief paragraph on 'const fn') - rust-lang#77923 ([net] apply clippy lints) - rust-lang#77931 (Fix false positive for `unused_parens` lint) - rust-lang#77959 (Tweak ui-tests structure) - rust-lang#78105 (change name in .mailmap) - rust-lang#78111 (Trait predicate ambiguities are not always in `Self`) - rust-lang#78121 (Do not ICE on pattern that uses a binding multiple times in generator) Failed merges: r? `@ghost`
…vel, r=Mark-Simulacrum BTreeMap: stop mistaking node::MIN_LEN for a node level constraint Correcting rust-lang#77612 that fell into the trap of assuming that node::MIN_LEN is an imposed minimum everywhere, and trying to make it much more clear it is an offered minimum at the node level. r? @Mark-Simulacrum
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? `@Mark-Simulacrum`
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? ``@Mark-Simulacrum``
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? ```@Mark-Simulacrum```
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? ````@Mark-Simulacrum````
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? `````@Mark-Simulacrum`````
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? ``````@Mark-Simulacrum``````
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? ```````@Mark-Simulacrum```````
… r=Mark-Simulacrum BTreeMap: stop mistaking node for an orderly place A second mistake in rust-lang#77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything. r? ````````@Mark-Simulacrum````````
r? @Mark-Simulacrum