#[expect(dead_code)] does not behave identically to #[allow(dead_code)]

[ojeda]

In its RFC, the #[expect(...)] lint attribute is said to function identically to #[allow(...)]. However, when trying out the attribute in the kernel, I found a case where I can see a difference.

The following code does not emit any warning:

fn f() {}

#[allow(dead_code)]
fn g() {
    f();
}

However, this does:

fn f() {}

#[expect(dead_code)]
fn g() {
    f();
}

In other words, with #[allow(...)], f is understood to be used, because it is called from g, even if g is dead code itself. With #[expect(...)], f is understood as not used.

Both 1.71.1 and nightly (32303b2 2023-07-29) behave the same way: https://godbolt.org/z/sMhYh1q11.

Cc'ing @xFrednet and @fmease who may be interested in this.

[xFrednet]

Interesting, I assume that this is due to the actual lint implementation. It probably somewhere checks for the lint level and has a == Allow in it.

[Urgau]

@rustbot claim

[dream-dasher]

I am still seeing this error despite the closing PR.
But I'm seeing it in a slightly pathological, but easy to reach scenario.

Problem

Code used by other code which isn't used will trigger unused-style lints (e.g. dead_code or unused_imports).
But, #[expect(_lint_)] will trigger an unfulfilled lint expectation warning.

(expect: catch-22)

Cause

This seems to occur when using a lib.rs and a main.rs, but directly importing the module in main.rs

For example, in my (not minimally simplified case)

> main.rs  <-- imports mod subscriber & use crate::subscriber::*;  ALSO uses use <crate_name>::*;
> lib.rs      <-- exports pub mod subscriber

>> support.rs
>> support/
>>> error.rs
>>> subscriber.rs

Directly using children files via mod in main while also importing via the library is an organizational mistake. But, if one is transitioning from a main-only to main+library setup then it is an easy mistake to make -- particularly with automated use additions in an IDE.

One approach, rather than 'fixing' the above behavior, might simply be checking and flagging that code is being namespaced via dual routes.
(Both would be ideal, I imagine. But I noticed that the above fix that hit the primary behavior was already more involved than expected.)

Environment

This is with Nightly & Edition2024

Edition : Edition2024

rustc --version
rustc 1.85.0-nightly (a224f3807 2024-12-09)

rust-analyzer --version
rust-analyzer 1.85.0-nightly (a224f380 2024-12-09)

cargo-clippy --version
clippy 0.1.85 (a224f3807e 2024-12-09)

rustup --version
rustup 1.27.1 (54dd3d00f 2024-04-24)

Examples - workaround & non-functioning woarkaround

Workaround (sometimes works):

impl CliErrorKind {
        /// Redundant with `ToOther(trait)::make_other_dyn_error`
        #[expect(
                clippy::allow_attributes,
                reason = "On or Off expect throws a warning. Lint warning or unfulfilled lint expectation warning."
        )]
        #[allow(dead_code, reason = "Boiler plate available for use.")]
        pub fn make_other_dyn_error<E>(error: E) -> Self
        where
                E: Into<Box<dyn std::error::Error + Send + Sync>>,
        {
                Self::OtherDynError { source: error.into() }
        }
}

In some cases the workaround fails, e.g.:

#[expect(
        clippy::allow_attributes,
)]
#[allow(unused_imports, reason = "Boiler plate available for use.")]
pub use subscriber::{generate_tracing_tree_subscriber, generate_tracing_fmt_subscriber};

Here generate_tracing_tree_subscriber is unused.
The unused_imports lint is set and can't be suppressed by #[expect..., but using #[expect...->#[allow... does not work (unlike above) -- instead a clippy::useless_attribute denial is generated.

[ojeda]

Does it only happen with nightly 1.85 and Edition 2024, or did you also try other versions/editions? Could you please reduce it to a small example if possible?

Thanks!