When `CONFIG_AUXILIARY_BUS` is disabled, `parent()` is still dead code:

    error: method `parent` is never used
      --> rust/kernel/device.rs:71:19
       |
    64 | impl<Ctx: DeviceContext> Device<Ctx> {
       | ------------------------------------ method in this implementation
    ...
    71 |     pub(crate) fn parent(&self) -> Option<&Self> {
       |                   ^^^^^^
       |
       = note: `-D dead-code` implied by `-D warnings`
       = help: to override `-D warnings` add `#[allow(dead_code)]`

Thus reintroduce the `expect`, but now as an `allow`, and do so as
`dead_code` since that is narrower.

Fixes: ce735e73dd59 ("rust: auxiliary: add auxiliary device / driver abstractions")
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
I should have noticed this earlier, sorry. Please feel free to rebase to
fix it directly there if you prefer.

 rust/kernel/device.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
index 40c1f549b0ba..e8ab4b9617db 100644
--- a/rust/kernel/device.rs
+++ b/rust/kernel/device.rs
@@ -68,6 +68,7 @@ pub(crate) fn as_raw(&self) -> *mut bindings::device {
     }

     /// Returns a reference to the parent device, if any.
+    #[allow(dead_code)]
     pub(crate) fn parent(&self) -> Option<&Self> {
         // SAFETY:
         // - By the type invariant `self.as_raw()` is always valid.

base-commit: ce735e73dd59b169b877cedd0753297c81c2a091
--
2.49.0

On Tue, Apr 29, 2025 at 05:03:46PM +0200, Miguel Ojeda wrote:
> When `CONFIG_AUXILIARY_BUS` is disabled, `parent()` is still dead code:
> 
>     error: method `parent` is never used
>       --> rust/kernel/device.rs:71:19
>        |
>     64 | impl<Ctx: DeviceContext> Device<Ctx> {
>        | ------------------------------------ method in this implementation
>     ...
>     71 |     pub(crate) fn parent(&self) -> Option<&Self> {
>        |                   ^^^^^^
>        |
>        = note: `-D dead-code` implied by `-D warnings`
>        = help: to override `-D warnings` add `#[allow(dead_code)]`
> 
> Thus reintroduce the `expect`, but now as an `allow`, and do so as
> `dead_code` since that is narrower.
> 
> Fixes: ce735e73dd59 ("rust: auxiliary: add auxiliary device / driver abstractions")
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Good catch, thanks!

I wonder if for such or similar cases we want something like

	macro_rules! cfg_expect {
	    (not($cfg:meta) => $lint:ident, $item:item) => {
		#[cfg(not($cfg))]
		#[expect($lint)]
		$item

		#[cfg($cfg)]
		$item
	    };
	}

which could be used like this:

    cfg_expect!(not(CONFIG_FEATURE) => dead_code,
        pub(crate) fn foo(&self) {
            // noop
        }
    );

Maybe there is a much better solution I don't know about.

On Tue, Apr 29, 2025 at 8:15 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Maybe there is a much better solution I don't know about.

There is `cfg_attr` for that, and we use it in a couple places, e.g.

    #[cfg_attr(not(CONFIG_AUXILIARY_BUS), expect(dead_code))]

But unless we are more or less sure the condition will only ever
depend on a single `cfg` or so, I am not sure if it is worth the
complexity (and even then reasonable people could disagree).

I wrote about that approach in the "Conditional compilation" in one of
the bullets of:

    https://docs.kernel.org/rust/coding-guidelines.html#lints

I hope that helps!

Cheers,
Miguel

On Tue, Apr 29, 2025 at 09:05:21PM +0200, Miguel Ojeda wrote:
> On Tue, Apr 29, 2025 at 8:15 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > Maybe there is a much better solution I don't know about.
> 
> There is `cfg_attr` for that, and we use it in a couple places, e.g.
> 
>     #[cfg_attr(not(CONFIG_AUXILIARY_BUS), expect(dead_code))]

Well, that is much better, thanks!

I prefer this then, I really want to catch if some other code starts using this.

- Danilo

On Tue, Apr 29, 2025 at 10:55 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Well, that is much better, thanks!
>
> I prefer this then, I really want to catch if some other code starts using this.

You're welcome! I will send v2 then, in case it is not "fixup"ed.

Cheers,
Miguel