[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <175775852994.709179.1112080420115135433.tip-bot2@tip-bot2>
Date: Sat, 13 Sep 2025 10:15:29 -0000
From: "tip-bot2 for Gary Guo" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Gary Guo <gary@...yguo.net>, Boqun Feng <boqun.feng@...il.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Benno Lossin <lossin@...nel.org>, Alexandre Courbot <acourbot@...dia.com>,
Elle Rhumsaa <elle@...thered-steel.dev>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject:
[tip: locking/core] rust: make `Arc::into_unique_or_drop` associated function
The following commit has been merged into the locking/core branch of tip:
Commit-ID: 9c0200e40fac9abd06575e4d10a3c4e186cb0d80
Gitweb: https://git.kernel.org/tip/9c0200e40fac9abd06575e4d10a3c4e186cb0d80
Author: Gary Guo <gary@...yguo.net>
AuthorDate: Thu, 04 Sep 2025 21:41:38 -07:00
Committer: Peter Zijlstra <peterz@...radead.org>
CommitterDate: Sat, 13 Sep 2025 12:07:58 +02:00
rust: make `Arc::into_unique_or_drop` associated function
Make `Arc::into_unique_or_drop` to become a mere associated function
instead of a method (i.e. removing the `self` receiver).
It's a general convention for Rust smart pointers to avoid having
methods defined on them, because if the pointee type has a method of the
same name, then it is shadowed. This is normally for avoiding semver
breakage, which isn't an issue for kernel codebase, but it's still
generally a good practice to follow this rule, so that `ptr.foo()` would
always be calling a method on the pointee type.
Signed-off-by: Gary Guo <gary@...yguo.net>
Signed-off-by: Boqun Feng <boqun.feng@...il.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Reviewed-by: Benno Lossin <lossin@...nel.org>
Reviewed-by: Alexandre Courbot <acourbot@...dia.com>
Reviewed-by: Elle Rhumsaa <elle@...thered-steel.dev>
Link: https://lore.kernel.org/r/20250723233312.3304339-3-gary@kernel.org
---
rust/kernel/sync/arc.rs | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/rust/kernel/sync/arc.rs b/rust/kernel/sync/arc.rs
index 63a6676..4ee155b 100644
--- a/rust/kernel/sync/arc.rs
+++ b/rust/kernel/sync/arc.rs
@@ -321,7 +321,7 @@ impl<T: ?Sized> Arc<T> {
/// use kernel::sync::{Arc, UniqueArc};
///
/// let arc = Arc::new(42, GFP_KERNEL)?;
- /// let unique_arc = arc.into_unique_or_drop();
+ /// let unique_arc = Arc::into_unique_or_drop(arc);
///
/// // The above conversion should succeed since refcount of `arc` is 1.
/// assert!(unique_arc.is_some());
@@ -337,18 +337,18 @@ impl<T: ?Sized> Arc<T> {
/// let arc = Arc::new(42, GFP_KERNEL)?;
/// let another = arc.clone();
///
- /// let unique_arc = arc.into_unique_or_drop();
+ /// let unique_arc = Arc::into_unique_or_drop(arc);
///
/// // The above conversion should fail since refcount of `arc` is >1.
/// assert!(unique_arc.is_none());
///
/// # Ok::<(), Error>(())
/// ```
- pub fn into_unique_or_drop(self) -> Option<Pin<UniqueArc<T>>> {
+ pub fn into_unique_or_drop(this: Self) -> Option<Pin<UniqueArc<T>>> {
// We will manually manage the refcount in this method, so we disable the destructor.
- let me = ManuallyDrop::new(self);
+ let this = ManuallyDrop::new(this);
// SAFETY: We own a refcount, so the pointer is still valid.
- let refcount = unsafe { me.ptr.as_ref() }.refcount.get();
+ let refcount = unsafe { this.ptr.as_ref() }.refcount.get();
// If the refcount reaches a non-zero value, then we have destroyed this `Arc` and will
// return without further touching the `Arc`. If the refcount reaches zero, then there are
@@ -365,7 +365,7 @@ impl<T: ?Sized> Arc<T> {
// must pin the `UniqueArc` because the values was previously in an `Arc`, and they pin
// their values.
Some(Pin::from(UniqueArc {
- inner: ManuallyDrop::into_inner(me),
+ inner: ManuallyDrop::into_inner(this),
}))
} else {
None
Powered by blists - more mailing lists