Skip to content

BTreeMap: better distinguish the root holder from the root node #75329

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Aug 11, 2020

Conversation

ssomers
Copy link
Contributor

@ssomers ssomers commented Aug 9, 2020

Renames and intermediate variables

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 9, 2020
@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Aug 9, 2020

📌 Commit ef753fc has been approved by Mark-Simulacrum

@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 Aug 9, 2020
@bors
Copy link
Collaborator

bors commented Aug 11, 2020

⌛ Testing commit ef753fc with merge 441fd22...

@bors
Copy link
Collaborator

bors commented Aug 11, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: Mark-Simulacrum
Pushing 441fd22 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 11, 2020
@bors bors merged commit 441fd22 into rust-lang:master Aug 11, 2020
@ssomers ssomers deleted the btree_cleanup_8 branch August 11, 2020 11:13
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 10, 2020
…ark-Simulacrum

BTreeMap: move up reference to map's root from NodeRef

Since the introduction of `NodeRef` years ago, it also contained a mutable reference to the owner of the root node of the tree (somewhat disguised as *const). Its intent is to be used only when the rest of the `NodeRef` is no longer needed. Moving this to where it's actually used, thought me 2 things:
- Some sort of "postponed mutable reference" is required in most places that it is/was used, and that's exactly where we also need to store a reference to the length (number of elements) of the tree, for the same reason. The length reference can be a normal reference, because the tree code does not care about tree length (just length per node).
- It's downright obfuscation in `from_sorted_iter` (transplanted to rust-lang#75329)
- It's one of the reasons for the scary notice on `reborrow_mut`, the other one being addressed in rust-lang#73971.

This does repeat the raw pointer code in a few places, but it could be bundled up with the length reference.

r? `@Mark-Simulacrum`
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
# for free to join this conversation on GitHub. Already have an account? # 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.

5 participants