Automatically derived trait implementations on `#[deprecated]` items emit warnings

[MrGunflame]

When using the #[automatically_derived] attribute on deprecated items, deprecation warnings are not omitted for that item. This does not affect macros from the stdlib.

The following code will not compile under these conditions:

#![deny(deprecated)]

#[deprecated]
struct DeprecatedItem;

trait MyTrait {}

// Imagine this block was derived.
#[automatically_derived]
impl MyTrait for DeprecatedItem {}

It would be possible to use #[allow(deprecated)] on the derived impl block to omit the warnings, but that affects the entire block instead of only DeprecatedItem. This will also not work if the #![forbid(deprecated)] lint is enabled.

I expected to see this happen: The code should compile despite and ignore the use of DeprecatedItem when within the [#automatically_derived] attribute.

Instead, this happened: The code does not compile.

Meta

rustc --version --verbose:

rustc 1.70.0-nightly (84dd17b56 2023-04-14)
binary: rustc
commit-hash: 84dd17b56a931a631a23dfd5ef2018fd3ef49108
commit-date: 2023-04-14
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.2

[Ezrashaw]

Note that this doesn't occur when standard #[derive(..)] is used.

#![deny(deprecated)]

#[deprecated]
#[derive(Copy, Clone)]
struct DeprecatedItem;

compiles without warnings.

[Jules-Bertholet]

@rustbot label +A-lint

[LikeLakers2]

Hi, I made a bug report on this issue, and didn't notice this old issue until now. So I'm copying the info I posted over at #135065.

tl;dr any sort of impl block for a deprecated struct causes a "use of deprecated item" warning - whether the impl block is in the same crate or not; whether the impl block is impl SomeStruct or impl Trait for SomeStruct (even for trait impls generated by derive attributes). The only exceptions to this are impl blocks generated by std's derives (i.e. #[derive(Clone)]).

My bug report

Code

extern crate serde; // 1.0.215

#[deprecated]
pub struct A;

impl A {}

#[deprecated]
#[derive(serde::Deserialize)]
pub struct B;

Current output

   Compiling playground v0.0.1 (/playground)
warning: use of deprecated struct `A`
 --> src/lib.rs:6:6
  |
6 | impl A {}
  |      ^
  |
  = note: `#[warn(deprecated)]` on by default

warning: use of deprecated struct `B`
  --> src/lib.rs:10:12
   |
10 | pub struct B;
   |            ^

warning: use of deprecated unit struct `B`
  --> src/lib.rs:10:12
   |
10 | pub struct B;
   |            ^

warning: `playground` (lib) generated 3 warnings
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.36s

Desired output

   Compiling playground v0.0.1 (/playground)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.62s

Rationale and extra context

When #[deprecated] is attached to a struct/enum, any impl blocks for that item (whether impl Struct or impl Trait for Struct) will trigger a "use of deprecated item" warning. This includes impl blocks generated by derives - even ones that attach #[automatically_derived] to the impl block (with the exception of std derives such as Clone).

Not only that, but the error caused by the derives points to the struct name itself, despite the linting item being from a derive - causing quite a bit of confusion. (This caused me some confusion when I attempted to attach #[expect(deprecated)] to a deprecated struct, only to be hit with a "lint expectation unfulfilled" because I technically wasn't attaching it to the right item.)

Ideally, this issue would not occur if the impl block and the deprecated item live in the same crate. We know that item is deprecated, but we are leaving the impl blocks there to avoid breaking anybody who consumes the crate.

Other cases

// N/A

Rust Version

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-pc-windows-msvc
release: 1.83.0
LLVM version: 19.1.1

Anything else?

• This issue was found while I was creating bevy_audio: Apply #![deny(clippy::allow_attributes, clippy::allow_attributes_without_reason)] bevyengine/bevy#17119.
• This issue can be reproduced on the Rust Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=044623639bee6d8b1576debd2b5c2afb