`unfulfilled_lint_expectation` warns on a lint that happens at MSRV but not at nightly

[ilyagr]

Summary

I'm not 100% sure this would be considered a bug, but I'm hoping it is.

Lint Name

unfulfilled_lint_expectation, redundant_clone

Reproducer

When I run cargo +nightly clippy --all-targets on https://github.com/jj-vcs/jj/tree/13477940af42a74a58caaaaeafdbd322cfebb81d I get this error:

warning: this lint expectation is unfulfilled
   --> lib/src/default_index/mod.rs:178:18
    |
178 |         #[expect(clippy::redundant_clone)] // Work around nightly clippy false positive
    |                  ^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unfulfilled_lint_expectations)]` on by default

warning: `jj-lib` (lib test) generated 1 warning

However, the MSRV for this code is 1.84, and cargo +1.84 clippy --all-targets does not trigger this warning.

I could of course change this to an allow(), but then we would forget to remove the exception when we increase our MSRV.

Version

rustc 1.88.0-nightly (b4c8b0c3f 2025-04-25)
binary: rustc
commit-hash: b4c8b0c3f0533bb342a4873ff59bdad3883ab8e3
commit-date: 2025-04-25
host: aarch64-apple-darwin
release: 1.88.0-nightly
LLVM version: 20.1.2

Additional Labels

No response

[profetia]

I think this means that the FP has been fixed in nightly.

[ilyagr]

Yes, but now unfulfilled_lint_expectation is a false positive (in the sense that mechanically removing the #[expect] would cause problems to the project), since the #[expect()] is still needed at the MSRV. If the MSRV was at 1.88, I wouldn't call it a false positive.

One workaround would be if I could manually specify that the expect is conditional on the Rustc version being below 1.88, I'm not sure whether that's doable. If clippy took care of everything automatically, that'd be even better :)

[Alexendoo]

Native support for version based cfg rust-lang/rust#64796 is unfortunately still stalled on cfg(accessible), but it's possible via the rustversion crate

Clippy continuing to fulfil lints based on MSRV would be impractical as it'd require keeping around every bug as an additional code path and record the version it's fixed in, that'd get out of hand quickly