Skip to content
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: better distinguish the root holder from the root node #75329

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
Contributor

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
Contributor

bors commented Aug 11, 2020

⌛ Testing commit ef753fc with merge 441fd22...

@bors
Copy link
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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