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

btree/node.rs: pub fn dormant should be marked as unsafe #136255

Open
btj opened this issue Jan 29, 2025 · 1 comment
Open

btree/node.rs: pub fn dormant should be marked as unsafe #136255

btj opened this issue Jan 29, 2025 · 1 comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@btj
Copy link
Contributor

btj commented Jan 29, 2025

This issue is about the "public" API of module alloc/src/collections/btree/node.rs. (The module itself is not public.)

I don't know how serious people are about pursuing strong static typing for this API, but depending on that, I think both dormant functions (on NodeRef and on Handle) should be marked as unsafe: the very existence of a dormant NodeRef/Handle is unsafe because it can be turned into a NodeRef<Immut<'a>, ...> using non-unsafe method reborrow and then inspected arbitrarily, which may cause races, aliasing rules violations, etc. with concurrent use of a NodeRef<Mut<'a>, ...> existing at the same time.

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jan 29, 2025
@fmease fmease added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Jan 29, 2025
@btj
Copy link
Contributor Author

btj commented Jan 29, 2025

In fact, should a dormant NodeRef be a NodeRef at all? Are there any operations at all that a client should be able to perform on a dormant NodeRef, other than awakening it? Would it not make more sense to introduce an entirely separate struct DormantNodeRef instead? That way, the dormant functions could remain non-unsafe. (Same for Handle.)

A related issue, by the way, is that the discussion of the possible values for BorrowType in the doc comment for NodeRef currently does not mention DormantMut.

@lolbinarycat lolbinarycat added the C-cleanup Category: PRs that clean code up or issues documenting cleanup. label Jan 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants