Skip to contentSkip to conversation

rust: kernel: clean explicit lifetimes that can be elided

RFC PATCH In review Miguel Ojeda 2 participants 2 messages Oct 12, 2024 – Oct 14, 2024 Rust

lore
Share & tools
lore

Miguel Ojeda

author maintainer
#0 lore raw

RFC PATCH 1/1 rust: kernel: clean explicit lifetimes that can be elided

In nightly Clippy (i.e. Rust 1.83.0), the needless_lifetimes lint has been extended [1] to suggest eliding impl lifetimes, e.g.

    error: the following explicit lifetimes could be elided: 'a
    --> rust/kernel/list.rs:647:6
        |
    647 | impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
        |      ^^                                                                  ^^
        |
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
        = note: `-D clippy::needless-lifetimes` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]`
    help: elide the lifetimes
        |
    647 - impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
    647 + impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {}

Thus clean them.

Link https://github.com/rust-lang/rust-clippy/pull/13286 [1]
Signed-off-by Miguel Ojeda <[email protected]>

---
Do we want this in general, or just in some cases? There is an issue about this where we may want to leave some feedback:

    https://github.com/rust-lang/rust-clippy/issues/13514
 rust/kernel/list.rs   |  2 +-
 rust/kernel/rbtree.rs | 14 +++++++-------
 2 files changed, 8 insertions(+), 8 deletions(-)
rust/kernel/list.rs +1 -1
index 5b4aec29eb67..cbccd932fa43 100644
@@ -644,7 +644,7 @@ pub fn remove(self) -> ListArc<T, ID> {
     }
 }
 
-impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
+impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {}
 
 impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> IntoIterator for &'a List<T, ID> {
     type IntoIter = Iter<'a, T, ID>;
rust/kernel/rbtree.rs +7 -7
index 25eb36fd1cdc..232a5eefa6f9 100644
@@ -729,13 +729,13 @@ pub struct Cursor<'a, K, V> {
 // SAFETY: The [`Cursor`] has exclusive access to both `K` and `V`, so it is sufficient to require them to be `Send`.
 // The cursor only gives out immutable references to the keys, but since it has excusive access to those same
 // keys, `Send` is sufficient. `Sync` would be okay, but it is more restrictive to the user.
-unsafe impl<'a, K: Send, V: Send> Send for Cursor<'a, K, V> {}
+unsafe impl<K: Send, V: Send> Send for Cursor<'_, K, V> {}
 
 // SAFETY: The [`Cursor`] gives out immutable references to K and mutable references to V,
 // so it has the same thread safety requirements as mutable references.
-unsafe impl<'a, K: Sync, V: Sync> Sync for Cursor<'a, K, V> {}
+unsafe impl<K: Sync, V: Sync> Sync for Cursor<'_, K, V> {}
 
-impl<'a, K, V> Cursor<'a, K, V> {
+impl<K, V> Cursor<'_, K, V> {
     /// The current node
     pub fn current(&self) -> (&K, &V) {
         // SAFETY:

@@ -948,11 +948,11 @@ pub struct Iter<'a, K, V> {
 
 // SAFETY: The [`Iter`] gives out immutable references to K and V, so it has the same
 // thread safety requirements as immutable references.
-unsafe impl<'a, K: Sync, V: Sync> Send for Iter<'a, K, V> {}
+unsafe impl<K: Sync, V: Sync> Send for Iter<'_, K, V> {}
 
 // SAFETY: The [`Iter`] gives out immutable references to K and V, so it has the same
 // thread safety requirements as immutable references.
-unsafe impl<'a, K: Sync, V: Sync> Sync for Iter<'a, K, V> {}
+unsafe impl<K: Sync, V: Sync> Sync for Iter<'_, K, V> {}
 
 impl<'a, K, V> Iterator for Iter<'a, K, V> {
     type Item = (&'a K, &'a V);

@@ -983,11 +983,11 @@ pub struct IterMut<'a, K, V> {
 // SAFETY: The [`IterMut`] has exclusive access to both `K` and `V`, so it is sufficient to require them to be `Send`.
 // The iterator only gives out immutable references to the keys, but since the iterator has excusive access to those same
 // keys, `Send` is sufficient. `Sync` would be okay, but it is more restrictive to the user.
-unsafe impl<'a, K: Send, V: Send> Send for IterMut<'a, K, V> {}
+unsafe impl<K: Send, V: Send> Send for IterMut<'_, K, V> {}
 
 // SAFETY: The [`IterMut`] gives out immutable references to K and mutable references to V, so it has the same
 // thread safety requirements as mutable references.
-unsafe impl<'a, K: Sync, V: Sync> Sync for IterMut<'a, K, V> {}
+unsafe impl<K: Sync, V: Sync> Sync for IterMut<'_, K, V> {}
 
 impl<'a, K, V> Iterator for IterMut<'a, K, V> {
     type Item = (&'a K, &'a mut V);

base-commit: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b --
2.47.0

reviewer Reviewed-by on v1 1/1
#1 lore raw
Quoted 20 lines · Miguel Ojeda

In nightly Clippy (i.e. Rust 1.83.0), the needless_lifetimes lint has been extended [1] to suggest eliding impl lifetimes, e.g.

    error: the following explicit lifetimes could be elided: 'a
    --> rust/kernel/list.rs:647:6
        |
    647 | impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
        |      ^^                                                                  ^^
        |
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
        = note: `-D clippy::needless-lifetimes` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]`
    help: elide the lifetimes
        |
    647 - impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
    647 + impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {}

Thus clean them.

Quoted 7 lines
Link https://github.com/rust-lang/rust-clippy/pull/13286 [1]
Signed-off-by Miguel Ojeda <[email protected]>

---
Do we want this in general, or just in some cases? There is an issue about this where we may want to leave some feedback:

    https://github.com/rust-lang/rust-clippy/issues/13514

If this lint lands for real, then this change LGTM:

Reviewed-by Alice Ryhl <[email protected]>

However, I don't think the lint is useful. I would rather that we are able to allow this lint.

Alice