#[deprecated] attribute not working "as expected" on pub use library crate exports

[d-e-s-o]

Perhaps I don't have the right mental model, but I find it extremely confusing that #[deprecated] does not do what it's supposed to do on a pub use statement (in a lib.rs, for example). Consider:

# foolib/src/lib.rs
mod foobar {
  pub struct Foo {
    pub i: u64,
  }
}

#[deprecated(note = "no longer needed")]
pub use foobar::Foo;

# fooapp/src/main.rs
use foolib::Foo;

fn main() {
    let foo = Foo {
      i: 42,
    };
    println!("Foo.i = {}", foo.i);
}

When compiling, no deprecation warning is emitted.

Instead, I am forced to use:

--- foolib/src/lib.rs
+++ foolib/src/lib.rs
@@ -1,8 +1,8 @@
 mod foobar {
+  #[deprecated(note = "no longer needed")]
   pub struct Foo {
     pub i: u64,
   }
 }

-#[deprecated(note = "no longer needed")]
 pub use foobar::Foo;

That in turn, now causes a deprecation warning to be emitted in the library crate itself.

Furthermore, no warning is emitted for the first version (#[deprecated] on the pub use statement) that it does not do what (clearly?) the user intends.

Meta

$ rustc --version --verbose
rustc 1.51.0 (gentoo)
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.51.0
LLVM version: 11.1.0

[d-e-s-o]

Reproduction case: foo.tar.gz

[d-e-s-o]

Also FWIW, the attribute documentation https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute does not explicitly say that it does not work on pub use statements (I am not that familiar with the grammar to say with confidence whether it should work on it). In any event, if it intentionally does not work, I'd at the very least expect a warning, more likely an error. Silently not doing the right thing is something I'd expect in other languages ;-)

[ehuss]

Thanks for the report! I do believe that it is intended to work, but it is a known bug. This has been reported a few times, see #84584, #47236, #30827, #23937.

[d-e-s-o]

Ah, thanks for the pointer. #84584 I found (but then forgot to mention as related), but deemed slightly different. #30827 seems to be about exactly the same issue. Closing then.