Unexpected deprecation warnings on the declaration of the deprecated enum

[richkadel]

PR #85617 had an unintended side effect that generates invalid warnings on enum declarations.

A simple example, below, demonstrates the issue. I reverted the change from that PR, and I don't get the warning, to validate that PR causes the problem.

This is a significant issue for projects that require warnings be treated as errors, so I hope we can prioritize a fix or revert of the change. Thanks!

I tried this code:

#[derive(Debug)]
pub struct Txid();

#[derive(Debug)]
#[deprecated(note = "Use EchoRequest instead")]
// #[allow(deprecated)] // required to avoid warning
pub enum EchoRequestMessage {
    EchoString { value: Option<String>, tx_id: Txid },
}

#[allow(deprecated)]
impl EchoRequestMessage {
    pub fn new() -> Self {
        EchoRequestMessage::EchoString { value: None, tx_id: Txid() }
    }
}

#[allow(deprecated)]
fn main() {
    let mess = EchoRequestMessage::new();
    println!("made a {:?}", mess);
}

I expected to see this happen: No warnings

I should not have to allow(deprecated) on the declaration of the deprecated thing.

Instead, this happened: I get a deprecation warning on the declaration of the thing that is declared as deprecated.

$ /usr/local/google/home/richkadel/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc test_deprecated.rs
warning: use of deprecated variant EchoRequestMessage::EchoString: Use EchoRequest instead
--> test_deprecated.rs:8:5
|
8 | EchoString { value: Option, tx_id: Txid },
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(deprecated)] on by default

warning: 1 warning emitted

Meta

rustc --version --verbose:

rustc 1.54.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.54.0-dev
LLVM version: 12.0.1

git log:

commit 595088d602049d821bf9a217f2d79aea40715208 (HEAD, upstream/master)
Merge: 289ada5ed41 896898ed43b
Author: bors <[email protected]>
Date:   Fri Jun 4 13:31:51 2021 +0000

[richkadel]

cc: @hi-rustin @estebank

[Mark-Simulacrum]

I think reverting it to start makes sense to me if it's having significant impact, I'd at least be happy to r+ such a revert (and the PR can be relanded later with a fix).

[richkadel]

@Mark-Simulacrum - Thank you! I just initiated a revert vis #86001.