Using deprecated items within the crate that deprecated them issues warnings

When deprecating an item, you typically still want the helper methods supporting it to work without the compiler whining that the item is deprecated.

I tried this code: playground

#[deprecated]
pub struct Foo;

impl Foo {
    fn foo() -> Foo { Foo }
}

I expected to see this happen: The code compiles without deprecation warnings.

Instead, this happened: Litterally every usage of Foo gets a use of deprecated item Foo warning.

The fact that I'm deprecating an item doesn't mean the crate itself should now be spammed with deprecation warnings. Working around it by either a global #![allow(deprecated)] will swallow legitimate deprecation warnings or require all uses to be tagged with it.

Meta

Playground, all channels (how do you get the version info from the playground?)

1. Whelp, I only read the RFC (rust-lang/rfcs#1270), not its accompanying tracking issue (#29935) where some people have written concerns about the extreme verbosity of deprecated warnings but the discussion died out.

   I was thinking in the direction of allowing access to deprecated items in the crate which defines it in its entirety but I imagine that's more something for rust-lang/rfcs. Still the extreme verbosity of deprecated warning deserves an issue.

   Casper at 2018-01-05 16:55:18

2. So I still have this issue. We deprecated a type, and suddenly we get tens of deprecation warnings of internal usage of this type, which are just method implementations on those types. Adding a deprecation warning to all these methods doesn't change anything.

   I tried adding #[allow(deprecated)] to the impl block of the deprecated type, but then I got this weird warning message without line number (albeit shorter):

   warning: use of deprecated item 'util::bip143::SighashComponents': please use `SigHashCache` instead
     |
     = note: `#[warn(deprecated)]` on by default
   
   warning: use of deprecated item 'util::bip143::SighashComponents': please use `SigHashCache` instead
   
       Finished dev [unoptimized + debuginfo] target(s) in 2.95s
   

   Steven Roose at 2020-01-16 11:39:08

3. Another related case is whether we should still output deprecated usage warnings for deprecated items inside an already deprecated item.

   Say we have an deprecated item Foo in crate foo, and we have below code (in crate foo or in another crate foo2)

   #[deprecated]
   pub fn drop_foo(f: Foo) {
   }
   

   In this case the usage is already in a deprecated function, there is little upside to change the already deprecated code. We can however to add an option if it may indeed be useful in some cases.

   Lu, Wangshan at 2021-04-02 09:15:13

4. When deprecating an item, you typically still want the helper methods supporting it to work without the compiler whining that the item is deprecated.

   Typically you want to know about all usages of a deprecated item, since you want to remove all usage of it. And where you want to temporarily still use it it makes sense to have to add #[allow(deprecated)]. I use the term "temporary" since long term the item will be removed.

   Triage: Changing to T-lang since I don't think it's self evident that this should be changed.

   Martin Nordholts at 2024-11-12 13:20:00

5. Typically you want to know about all usages of a deprecated item, since you want to remove all usage of it. And where you want to temporarily still use it it makes sense to have to add #[allow(deprecated)]. I use the term "temporary" since long term the item will be removed.

   When I made this issue I came from a perspective of using deprecated as a tool to guide consumers of the crate on what to use (without breaking compatibility).

   Within my own crate I can just xref all uses and break/fix things as there is no compatibility hazard.

   Casper at 2024-11-15 19:43:16