[PATCH] rust: kunit: avoid retain_mut for test attr filtering

0 views
Skip to first unread message

Elsanti

unread,
Feb 25, 2026, 3:27:39 PM (2 days ago) Feb 25
to brendan...@linux.dev, davi...@google.com, oj...@kernel.org, raem...@gmail.com, bo...@kernel.org, ga...@garyguo.net, bjor...@protonmail.com, los...@kernel.org, a.hin...@kernel.org, alic...@google.com, tmg...@umich.edu, da...@kernel.org, linux-k...@vger.kernel.org, kuni...@googlegroups.com, rust-fo...@vger.kernel.org, linux-...@vger.kernel.org, Elsanti
Remove the unnecessary mutable borrow when stripping #[test] attributes:
retain() is sufficient to drop test markers while tracking their presence.
This keeps the logic compatible with the current MSRV and avoids extra
mutability.

Signed-off-by: Elsanti <santiagoj...@gmail.com>
---
rust/macros/kunit.rs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
index e064419bfc10..083b8fe39e6c 100644
--- a/rust/macros/kunit.rs
+++ b/rust/macros/kunit.rs
@@ -88,7 +88,7 @@ pub(crate) fn kunit_tests(test_suite: Ident, mut module: ItemMod) -> Result<Toke
};

let mut had_test_attr = false;
- f.attrs.retain_mut(|attr| {
+ f.attrs.retain(|attr| {
let is_test = attr.path().is_ident("test");
if is_test {
had_test_attr = true;
--
2.53.0

Gary Guo

unread,
Feb 25, 2026, 4:04:17 PM (2 days ago) Feb 25
to Elsanti, brendan...@linux.dev, davi...@google.com, oj...@kernel.org, raem...@gmail.com, bo...@kernel.org, bjor...@protonmail.com, los...@kernel.org, a.hin...@kernel.org, alic...@google.com, tmg...@umich.edu, da...@kernel.org, linux-k...@vger.kernel.org, kuni...@googlegroups.com, rust-fo...@vger.kernel.org, linux-...@vger.kernel.org
On 2026-02-25 20:27, Elsanti wrote:
> Remove the unnecessary mutable borrow when stripping #[test] attributes:
> retain() is sufficient to drop test markers while tracking their presence.
> This keeps the logic compatible with the current MSRV and avoids extra
> mutability.
>
> Signed-off-by: Elsanti <santiagoj...@gmail.com>

New versions should be sent if you want to amend your patch, not a new commit
on top of it.

Best,
Gary
Reply all
Reply to author
Forward
0 new messages