[PATCH v2] rust: add mark_used macro

From: FUJITA Tomonori <fujita.tomonori@gmail.com>

Macros whose expansion depends on the kernel configuration end up
ignoring some of their arguments, resulting in unused warnings.

Add a macro for the `if false { _ = ...; }` idiom used to avoid them,
and convert the existing open-coded users in `warn_flags!` and
`declare_trace!`.

Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
v2:
- Drop the comment in `declare_trace!`. The macro name says the same thing.
- Add Gary's Reviewed-by.
- Rebase on rust-next.
v1: https://lore.kernel.org/rust-for-linux/20260810075144.1245761-1-tomo@flapping.org/
---
 rust/kernel/bug.rs        | 18 ++++--------------
 rust/kernel/lib.rs        | 12 ++++++++++++
 rust/kernel/tracepoint.rs |  4 +---
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/rust/kernel/bug.rs b/rust/kernel/bug.rs
index 3566f0234ca4..c1e4eb7d4a70 100644
--- a/rust/kernel/bug.rs
+++ b/rust/kernel/bug.rs

@@ -55,9 +55,7 @@ macro_rules! warn_flags {
     ($file:expr, $flags:expr) => {
         const FLAGS: u32 = $crate::bindings::BUGFLAG_WARNING | $flags;
 
-        if false {
-            _ = $file;
-        }
+        $crate::mark_used!($file);
 
         // SAFETY:
         // - `flags` and `size` are all compile-time constants, preventing

@@ -83,9 +81,7 @@ macro_rules! warn_flags {
 #[cfg(all(CONFIG_BUG, CONFIG_UML))]
 macro_rules! warn_flags {
     ($file:expr, $flags:expr) => {
-        if false {
-            _ = $file;
-        }
+        $crate::mark_used!($file);
 
         // SAFETY: It is always safe to call `warn_slowpath_fmt()`
         // with a valid null-terminated string.

@@ -106,10 +102,7 @@ macro_rules! warn_flags {
 #[cfg(all(CONFIG_BUG, any(CONFIG_LOONGARCH, CONFIG_ARM)))]
 macro_rules! warn_flags {
     ($file:expr, $flags:expr) => {
-        if false {
-            _ = $file;
-            _ = $flags;
-        }
+        $crate::mark_used!($file, $flags);
 
         // SAFETY: It is always safe to call `WARN_ON()`.
         unsafe { $crate::bindings::WARN_ON(true) }

@@ -121,10 +114,7 @@ macro_rules! warn_flags {
 #[cfg(any(testlib, not(CONFIG_BUG)))]
 macro_rules! warn_flags {
     ($file:expr, $flags:expr) => {
-        if false {
-            _ = $file;
-            _ = $flags;
-        }
+        $crate::mark_used!($file, $flags);
     };
 }
 

diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index 4d5c96ddc49c..3b38e6b8196b 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs

@@ -227,6 +227,18 @@ macro_rules! container_of {
 #[doc(hidden)]
 pub fn assert_same_type<T>(_: T, _: T) {}
 
+/// Marks the given expressions as used.
+///
+/// This avoids "unused" warnings in kernel configurations that do not otherwise use them.
+#[macro_export]
+macro_rules! mark_used {
+    ($($e:expr),* $(,)?) => {
+        if false {
+            $( _ = $e; )*
+        }
+    };
+}
+
 /// Helper for `.rs.S` files.
 #[doc(hidden)]
 #[macro_export]

diff --git a/rust/kernel/tracepoint.rs b/rust/kernel/tracepoint.rs
index c6e80aa99e8e..29d2d2d0aca8 100644
--- a/rust/kernel/tracepoint.rs
+++ b/rust/kernel/tracepoint.rs

@@ -38,9 +38,7 @@ macro_rules! declare_trace {
 
             #[cfg(not(CONFIG_TRACEPOINTS))]
             {
-                // If tracepoints are disabled, insert a trivial use of each argument
-                // to avoid unused argument warnings.
-                $( let _unused = $argname; )*
+                $crate::mark_used!($($argname),*);
             }
         }
     )*}

base-commit: 28924df2a08f440c73991b83028032c901de2ae4
-- 
2.43.0

Hi Alice, Steven,

On Wed,  9 Sep 2026 21:02:10 +0900
FUJITA Tomonori [off-list ref] wrote:

Macros whose expansion depends on the kernel configuration end up
ignoring some of their arguments, resulting in unused warnings.

Add a macro for the `if false { _ = ...; }` idiom used to avoid them,
and convert the existing open-coded users in `warn_flags!` and
`declare_trace!`.

Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
---
v2:
- Drop the comment in `declare_trace!`. The macro name says the same thing.
- Add Gary's Reviewed-by.
- Rebase on rust-next.
v1: https://lore.kernel.org/rust-for-linux/20260810075144.1245761-1-tomo@flapping.org/
---
 rust/kernel/bug.rs        | 18 ++++--------------
 rust/kernel/lib.rs        | 12 ++++++++++++
 rust/kernel/tracepoint.rs |  4 +---
 3 files changed, 17 insertions(+), 17 deletions(-)

(snip)

Gentle ping. Could you take a look at the tracepoint.rs part? If it
looks fine, I think it is easiest to take the patch through the Rust
tree.

On Wed, Sep 30, 2026 at 06:50:28PM +0900, FUJITA Tomonori wrote:

quoted

diff --git a/rust/kernel/tracepoint.rs b/rust/kernel/tracepoint.rs
index c6e80aa99e8e..29d2d2d0aca8 100644
--- a/rust/kernel/tracepoint.rs
+++ b/rust/kernel/tracepoint.rs

@@ -38,9 +38,7 @@ macro_rules! declare_trace {
 
             #[cfg(not(CONFIG_TRACEPOINTS))]
             {
-                // If tracepoints are disabled, insert a trivial use of each argument
-                // to avoid unused argument warnings.
-                $( let _unused = $argname; )*
+                $crate::mark_used!($($argname),*);
             }
         }
     )*}

Gentle ping. Could you take a look at the tracepoint.rs part? If it
looks fine, I think it is easiest to take the patch through the Rust
tree.

Why are we adding this macro?

I think it's better to prefer avoiding macros if we can. The current
code is familiar to people who know Rust idioms, and now you are
replacing it with a kernel-specific macro that such people will not be
familiar with.

Alice

On Thu, 1 Oct 2026 11:05:52 +0000
Alice Ryhl [off-list ref] wrote:

On Wed, Sep 30, 2026 at 06:50:28PM +0900, FUJITA Tomonori wrote:

quoted

quoted

diff --git a/rust/kernel/tracepoint.rs b/rust/kernel/tracepoint.rs
index c6e80aa99e8e..29d2d2d0aca8 100644
--- a/rust/kernel/tracepoint.rs
+++ b/rust/kernel/tracepoint.rs

@@ -38,9 +38,7 @@ macro_rules! declare_trace {
 
             #[cfg(not(CONFIG_TRACEPOINTS))]
             {
-                // If tracepoints are disabled, insert a trivial use of each argument
-                // to avoid unused argument warnings.
-                $( let _unused = $argname; )*
+                $crate::mark_used!($($argname),*);
             }
         }
     )*}

Gentle ping. Could you take a look at the tracepoint.rs part? If it
looks fine, I think it is easiest to take the patch through the Rust
tree.

Why are we adding this macro?

I think it's better to prefer avoiding macros if we can. The current
code is familiar to people who know Rust idioms, and now you are
replacing it with a kernel-specific macro that such people will not be
familiar with.

The macro was suggested by Miguel:

https://lore.kernel.org/rust-for-linux/CANiq72nWcqd3aSKdPqOSRRQBuwWNW-s2EOscYszQ9kSbmrKxcw@mail.gmail.com/

I think you also have a point.

Miguel, what do you think?

On Thu, Oct 1, 2026 at 2:04 PM FUJITA Tomonori [off-list ref] wrote:

Miguel, what do you think?

I suggested it due to seeing the multi-line combination of `if false`
and `_ = ...`, and the fact that we will probably want to reuse the
combination in other macros. It makes the concept more explicit,
easier to grep, and follows other cases we have created for similar
things like this (e.g. `static_assert!`).

Having said that, I do prefer using plain language instead of macros
where possible/reasonable, i.e. I don't like introducing macros and
more concepts in general just for the sake of it. On the other hand,
sometimes language features aren't the best spellings to be honest
(like the `const _` "abuse") and some people prefer abbreviations
(like the discussion on `SZ_*` constants).

Either way is fine, obviously.

Cheers,
Miguel

On Thu, 1 Oct 2026 15:02:40 +0200
Miguel Ojeda [off-list ref] wrote:

On Thu, Oct 1, 2026 at 2:04 PM FUJITA Tomonori [off-list ref] wrote:

quoted

Miguel, what do you think?

I suggested it due to seeing the multi-line combination of `if false`
and `_ = ...`, and the fact that we will probably want to reuse the
combination in other macros. It makes the concept more explicit,
easier to grep, and follows other cases we have created for similar
things like this (e.g. `static_assert!`).

Having said that, I do prefer using plain language instead of macros
where possible/reasonable, i.e. I don't like introducing macros and
more concepts in general just for the sake of it. On the other hand,
sometimes language features aren't the best spellings to be honest
(like the `const _` "abuse") and some people prefer abbreviations
(like the discussion on `SZ_*` constants).

Either way is fine, obviously.

Thanks, I'll drop it.