[PATCH] rust: rbtree: simplify finding `current` in `remove_current`

[PATCH] rust: rbtree: simplify finding `current` in `remove_current`

[Onur Özkan]

The previous version used a verbose `match` to get
`current`, which may be slightly confusing at first
glance.

This change makes it shorter and more clearly expresses
the intent: prefer `next` if available, otherwise fall
back to `prev`.

Signed-off-by: Onur Özkan <work@onurozkan.dev>
---
 rust/kernel/rbtree.rs | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/rust/kernel/rbtree.rs b/rust/kernel/rbtree.rs
index 8d978c896747..8f1052552132 100644
--- a/rust/kernel/rbtree.rs
+++ b/rust/kernel/rbtree.rs
@@ -769,18 +769,10 @@ pub fn remove_current(self) -> (Option<Self>, RBTreeNode<K, V>) {
         // the tree cannot change. By the tree invariant, all nodes are valid.
         unsafe { bindings::rb_erase(&mut (*this).links, addr_of_mut!(self.tree.root)) };

-        let current = match (prev, next) {
-            (_, Some(next)) => next,
-            (Some(prev), None) => prev,
-            (None, None) => {
-                return (None, node);
-            }
-        };
-
         (
-            // INVARIANT:
-            // - `current` is a valid node in the [`RBTree`] pointed to by `self.tree`.
-            Some(Self {
+            next.or(prev).map(|current| Self {
+                // INVARIANT:
+                // - `current` is a valid node in the [`RBTree`] pointed to by `self.tree`.
                 current,
                 tree: self.tree,
             }),
--
2.50.0

Re: [PATCH] rust: rbtree: simplify finding `current` in `remove_current`

[Alice Ryhl]

On Fri, Jul 04, 2025 at 08:45:39AM +0300, Onur Özkan wrote:
> The previous version used a verbose `match` to get
> `current`, which may be slightly confusing at first
> glance.
> 
> This change makes it shorter and more clearly expresses
> the intent: prefer `next` if available, otherwise fall
> back to `prev`.
> 
> Signed-off-by: Onur Özkan <work@onurozkan.dev>
> ---
>  rust/kernel/rbtree.rs | 14 +++-----------
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/rust/kernel/rbtree.rs b/rust/kernel/rbtree.rs
> index 8d978c896747..8f1052552132 100644
> --- a/rust/kernel/rbtree.rs
> +++ b/rust/kernel/rbtree.rs
> @@ -769,18 +769,10 @@ pub fn remove_current(self) -> (Option<Self>, RBTreeNode<K, V>) {
>          // the tree cannot change. By the tree invariant, all nodes are valid.
>          unsafe { bindings::rb_erase(&mut (*this).links, addr_of_mut!(self.tree.root)) };
> 
> -        let current = match (prev, next) {
> -            (_, Some(next)) => next,
> -            (Some(prev), None) => prev,
> -            (None, None) => {
> -                return (None, node);
> -            }
> -        };
> -
>          (
> -            // INVARIANT:
> -            // - `current` is a valid node in the [`RBTree`] pointed to by `self.tree`.
> -            Some(Self {
> +            next.or(prev).map(|current| Self {
> +                // INVARIANT:
> +                // - `current` is a valid node in the [`RBTree`] pointed to by `self.tree`.
>                  current,
>                  tree: self.tree,
>              }),

I'm okay with this change, but the INVARIANT: comment usually goes
before the `StructName {` declaration rather than on the field. For
example, what about this?

	// INVARIANT:
	// - `current` is a valid node in the [`RBTree`] pointed to by `self.tree`.
	let cursor = next.or(prev).map(|current| Self {
	    current,
	    tree: self.tree,
	});
	
	(cursor, node)

Alice

Re: [PATCH] rust: rbtree: simplify finding `current` in `remove_current`

[Onur]

On Fri, 4 Jul 2025 07:36:16 +0000
Alice Ryhl <aliceryhl@google.com> wrote:

> On Fri, Jul 04, 2025 at 08:45:39AM +0300, Onur Özkan wrote:
> > The previous version used a verbose `match` to get
> > `current`, which may be slightly confusing at first
> > glance.
> > 
> > This change makes it shorter and more clearly expresses
> > the intent: prefer `next` if available, otherwise fall
> > back to `prev`.
> > 
> > Signed-off-by: Onur Özkan <work@onurozkan.dev>
> > ---
> >  rust/kernel/rbtree.rs | 14 +++-----------
> >  1 file changed, 3 insertions(+), 11 deletions(-)
> > 
> > diff --git a/rust/kernel/rbtree.rs b/rust/kernel/rbtree.rs
> > index 8d978c896747..8f1052552132 100644
> > --- a/rust/kernel/rbtree.rs
> > +++ b/rust/kernel/rbtree.rs
> > @@ -769,18 +769,10 @@ pub fn remove_current(self) -> (Option<Self>,
> > RBTreeNode<K, V>) { // the tree cannot change. By the tree
> > invariant, all nodes are valid. unsafe { bindings::rb_erase(&mut
> > (*this).links, addr_of_mut!(self.tree.root)) };
> > 
> > -        let current = match (prev, next) {
> > -            (_, Some(next)) => next,
> > -            (Some(prev), None) => prev,
> > -            (None, None) => {
> > -                return (None, node);
> > -            }
> > -        };
> > -
> >          (
> > -            // INVARIANT:
> > -            // - `current` is a valid node in the [`RBTree`]
> > pointed to by `self.tree`.
> > -            Some(Self {
> > +            next.or(prev).map(|current| Self {
> > +                // INVARIANT:
> > +                // - `current` is a valid node in the [`RBTree`]
> > pointed to by `self.tree`. current,
> >                  tree: self.tree,
> >              }),
> 
> I'm okay with this change, but the INVARIANT: comment usually goes
> before the `StructName {` declaration rather than on the field. For
> example, what about this?
> 
> 	// INVARIANT:
> 	// - `current` is a valid node in the [`RBTree`] pointed to
> by `self.tree`. let cursor = next.or(prev).map(|current| Self {
> 	    current,
> 	    tree: self.tree,
> 	});
> 	
> 	(cursor, node)

Looks nice. Do you want me to send v2 right away, or wait couple of days
to give sometime to other reviewers?

Regards,
Onur

Re: [PATCH] rust: rbtree: simplify finding `current` in `remove_current`

[Miguel Ojeda]

On Fri, Jul 4, 2025 at 5:14 PM Onur <work@onurozkan.dev> wrote:
>
> Looks nice. Do you want me to send v2 right away, or wait couple of days
> to give sometime to other reviewers?

Unless there is a particular reason (e.g. it needs to land quickly),
in general it is best to wait at least a few days.

Cheers,
Miguel