-
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: clarify comments and panics around choose_parent_kv #79376
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I wrong that
parent_edge.descend() == self
here?
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:
|
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. |
4c369ac
to
5057642
Compare
Back to basics then. @rustbot modify labels: +S-waiting-on-review -S-waiting-on-author |
@bors r+ |
📌 Commit 5057642 has been approved by |
☀️ 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