Re: [PATCH v1] rust: bug: prevent dead_code warning from warn_on!'s flags constant

FUJITA Tomonori <[email protected]>
Newsgroups org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Sun, 19 Jul 2026 22:54:24 -0700
Boqun Feng <[email protected]> wrote:

> On Mon, Jul 20, 2026 at 12:55:10PM +0900, FUJITA Tomonori wrote:
>> From: FUJITA Tomonori <[email protected]>
>> 
>> Fix the following dead_code warning on some configurations in an
>> atomic development branch:
>> 
>> warning: constant `WARN_ON_FLAGS` is never used
>>    --> /linux/rust/kernel/bug.rs:126:19
>>     |
>> 126 |               const WARN_ON_FLAGS: u32 = $crate::bug::bugflag_taint($crate::bindings::TAINT_WARN);
>>     |                     ^^^^^^^^^^^^^
>>     |
>>    ::: /linux/rust/kernel/sync/srcu.rs:106:12
>>     |
>> 106 |           if crate::warn_on!(
>>     |  ____________-
>> 107 | |             // SAFETY: By the type invariants, `self` contains a valid and pinned `struct srcu_struct`
>> 108 | |             // and `srcu_readers_active()` only checks the active reader count.
>> 109 | |             unsafe { bindings::srcu_readers_active(ptr) }
>> 110 | |         ) {
>>     | |_________- in this macro invocation
>>     |
>>     = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
>>     = note: this warning originates in the macro `crate::warn_on` (in Nightly builds, run with -Z macro-backtrace for more info)
>> 
>> The warn_on! macro always defines a WARN_ON_FLAGS constant and hands it
>> to warn_flags!. On configurations where warn_flags! does not reference
>> its flags argument (the LOONGARCH/ARM variant, which only calls
>> WARN_ON(), and the !CONFIG_BUG no-op variant), the constant is left
>> unused and triggers a dead_code warning.
>> 
>> The warning only surfaces for callers inside the kernel crate itself:
>> uses from other crates expand an external macro, so the lint is
>> suppressed there.
>> 
>> Rename the constant to _WARN_ON_FLAGS so the underscore marks it as
>> possibly-unused, matching the existing _COND_STR constant in the same
>> macro. The name is still referenceable, so configurations that do use
>> the flags are unaffected.
>> 
>> Signed-off-by: FUJITA Tomonori <[email protected]>
> 
> [Cc Paul]
> 
> Do we need a "Fixes" tag here?

Right, we likely do.

Fixes: dff64b072708 ("rust: Add warn_on macro")


> FWIW:
> 
> Reviewed-by: Boqun Feng <[email protected]>

Thanks!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.