BTreeMap: clarify comments and panics around choose_parent_kv #79376
Conversation
rust-highfive
added
the
S-waiting-on-review
| right_child: right_parent_kv.right_edge().descend(), | ||
| })), | ||
| Err(_) => unreachable!("empty non-root node"), | ||
| Err(parent_edge) => Err(parent_edge.descend()), |
There was a problem hiding this comment.
Am I wrong that parent_edge.descend() == self here? AFAICT, if we're in this branch that should be the case, but maybe I'm overlooking something?
Regardless it seems like we should error out on such an invalid state (at least a debug assert seems reasonable); do you think otherwise? I guess this is used during balancing, and we may have temporarily invalid nodes in that context.
There was a problem hiding this comment.
Am I wrong that
parent_edge.descend() == selfhere?
Indeed. Well, child at the moment, but now I don't see the point taking that child snapshot up front.
Regardless it seems like we should error out on such an invalid state (at least a debug assert seems reasonable); do you think otherwise?
I'm balancing on one foot on the otherwise side. The node module doesn't list emptiness (or underfullness) as an invariant, and we can't easily impose it. None of the node methods list it as a requirement, though others like choose_parent_kv may forget to mention it, and for instance key_at implies the node cannot be empty. We do have empty parent nodes during map algorithms, and at times not handling empty parents the same as absent parents caused trouble, though now I'm pretty sure the algorithms guarantee that the map layer can never invoke choose_parent_kv on the child of an empty node.
However the source of this PR is what it didn't fix: my annoyance with the type erasure and the cast_to_leaf_unchecked up in remove.rs. Let me try a little harder to work that out.
|
☔ The latest upstream changes (presumably #79529) 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: |
ssomers
force-pushed
the
btree_choose_parent_kv
branch
2 times, most recently
from
e0478c4
to
4c369ac
Compare
|
I feel like I am unconvinced with this PR being an improvement, and I'd prefer to leave things as-is if we don't have a clear goal in mind. It seems like the primary change in this PR is shifting from choose_parent_kv return Result depending on if we were in a root node already or not to panicking and the checking moving into the caller -- that doesn't seem like an improvement to me. |
Mark-Simulacrum
added
S-waiting-on-author
ssomers
force-pushed
the
btree_choose_parent_kv
branch
from
4c369ac
to
5057642
Compare
|
Back to basics then. @rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
rustbot
added
S-waiting-on-review
ssomers
changed the title
ssomers
changed the title
|
@bors r+ |
|
📌 Commit 5057642 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Fixes a lie in recent code:
unreachable!("empty non-root node")should shout "empty internal node", but it might as well be good and keep quietr? @Mark-Simulacrum