Derives on deprecated items generate deprecation warnings

[cramertj]

The following code generates a warning on nightly and beta but not on stable:

#[deprecated = "oh no"]
#[derive(Default)]
struct X;

[Centril]

Hmm; technically generating warnings seems like correct but annoying behavior (which we don't have to fix but probably should...). Putting #[allow(deprecated)] on generated impls seems like a solution?

[joshlf]

This regression also breaks existing code with #[deny(warnings)].

[nox]

derive attributes can only be put on the type but the same people than the ones who control the deprecated attribute, so I don't see how that's technically correct. Derives should only ever generate a deprecated warning if the trait they derive is deprecated, never because of the type's deprecatedness.

[asajeffrey]

Just hit this in servo...

warning: use of deprecated item 'vr_display_capabilities::VRDisplayCapabilities::presented_by_browser': please use `future_frame_data` instead
 --> /Users/ajeffrey/github/asajeffrey/rust-webvr/rust-webvr-api/src/vr_display_capabilities.rs:3:52
  |
3 | #[cfg_attr(feature = "serde-serialization", derive(Deserialize, Serialize))]
  |                                                    ^^^^^^^^^^^
  |
  = note: #[warn(deprecated)] on by default

warning: use of deprecated item 'vr_display_capabilities::VRDisplayCapabilities::presented_by_browser': please use `future_frame_data` instead
 --> /Users/ajeffrey/github/asajeffrey/rust-webvr/rust-webvr-api/src/vr_display_capabilities.rs:3:52
  |
3 | #[cfg_attr(feature = "serde-serialization", derive(Deserialize, Serialize))]
  |                                                    ^^^^^^^^^^^

warning: use of deprecated item 'vr_display_capabilities::VRDisplayCapabilities::presented_by_browser': please use `future_frame_data` instead
 --> /Users/ajeffrey/github/asajeffrey/rust-webvr/rust-webvr-api/src/vr_display_capabilities.rs:3:65
  |
3 | #[cfg_attr(feature = "serde-serialization", derive(Deserialize, Serialize))]
  |                                                                 ^^^^^^^^^

Caused by deprecating a field in a struct.

[joshlf]

Just hit this in Mundane too. We #![deny(warnings)], so it causes compilation failure.

error: use of deprecated item 'hash::InsecureSha1': SHA-1 is considered insecure
   --> src/hash.rs:102:10
    |
102 | #[derive(Default)]
    |          ^^^^^^^
    |
note: lint level defined here
   --> src/lib.rs:45:9
    |
45  | #![deny(warnings)]
    |         ^^^^^^^^
    = note: #[deny(deprecated)] implied by #[deny(warnings)]

error: use of deprecated item 'hash::InsecureSha1': SHA-1 is considered insecure
   --> src/hash.rs:102:10
    |
102 | #[derive(Default)]
    |          ^^^^^^^

error: use of deprecated item 'hash::InsecureSha1': SHA-1 is considered insecure
   --> src/hash.rs:102:10
    |
102 | #[derive(Default)]
    |          ^^^^^^^
    |
note: lint level defined here
   --> src/lib.rs:45:9
    |
45  | #![deny(warnings)]
    |         ^^^^^^^^
    = note: #[deny(deprecated)] implied by #[deny(warnings)]

error: use of deprecated item 'hash::InsecureSha1': SHA-1 is considered insecure
   --> src/hash.rs:102:10
    |
102 | #[derive(Default)]
    |          ^^^^^^^

error: use of deprecated item 'hash::InsecureSha1::ctx': SHA-1 is considered insecure
   --> src/hash.rs:104:5
    |
104 |     ctx: CStackWrapper<boringssl::SHA_CTX>,
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[pnkfelix]

triage: P-high

[nikomatsakis]

I'm currently running a bisection with cargo-bisect-rustc.

[nikomatsakis]

Regression is tracked to c84e797, which is #58098, cc @oli-obk -- this PR is titled " Require a list of features in #[allow_internal_unstable] #58098 ", one can certainly imagine how it could be related to this problem, perhaps the list of "allowed unstable features" for derives simply needs to be extended?

[pnkfelix]

speculatively assigning to @oli-obk based on @nikomatsakis 's bisection.

[oli-obk]

This is definitely caused by this change. We used to just not emit deprecation warnings inside allow_internal_unstable code. I'll extend derives to add #[allow(deprecated)] to replicate the previous behaviour, but we should probably create something more fine grained some day.