Allow deprecating a re-export

Opened by Sean McArthur at 2024-12-28 13:35:55

This would allow a module to rename an identifier without breaking users, and provide a message that they should change.

Example:

mod foo {
    #[deprecated(reason = "use Foo instead")]
    pub use self::Foo as Bar;

    pub struct Foo(pub i32);
}

use self::foo::Bar; // <- deprecrated, use Foo instead

Triage: the final syntax for deprecated uses note instead of reason:
```
mod foo {
    #[deprecated(note = "use Foo instead")]
    pub use self::Foo as Bar;

    pub struct Foo(pub i32);
}

use self::foo::Bar; // <- deprecrated, use Foo instead
```
however, this still reproduces. With no comments in two years, I'm not sure if this will ever be implemented. @rust-lang/lang , is this feature desired?
Steve Klabnik at 2018-09-24 16:14:45
I'd like to see this; deprecated should work on any declaration.
Josh Triplett at 2018-09-24 16:42:11
I agree with @joshtriplett.
Mazdak Farrokhzad at 2018-09-24 16:46:58
IIUC, in the current system, by the time stability/deprecation checks run, information about where you got something from, is lost (it's transient during name resolution). cc @petrochenkov
Eduard-Mihai Burtescu at 2018-09-24 17:55:25
E-help-wanted I'm unlikely to work on this in the next couple of years, and have no desire to mentor on this specific issue (that is sill significant work). Someone just needs to do this thankless job and 1) (preferable) move stability/deprecation checking to resolve phase or 2) (not preferable) keep relevant data in HIR to perform stability/deprecation checking where it's currently performed.
Vadim Petrochenkov at 2018-09-24 22:23:38
Same issue - https://github.com/rust-lang/rust/issues/23937.
Vadim Petrochenkov at 2018-09-24 22:24:34
@petrochenkov Would it be a good idea to integrate stability / deprecation with visibility a bit more? That is, the result of path / associated item / field / etc. name resolution can be:
- accessible
  - optionally deprecated
- not accessible, because it's:
  - private
  - unstable
And these would compose across the entire import chain to that destination.

However, one complicated aspect is how hierarchical stability is - if something is not annotated, one of its parents might be instead, and that's where it's inherited from. OTOH, (path) name resolution should already have access to the DefId tree, for... privacy checking!

So we'd be doing the "reverse" computation (walking up parents), which shouldn't be significantly more expensive, if we're caching everything computed along the way.
Eduard-Mihai Burtescu at 2018-09-26 06:50:20
@eddyb Merging visibility and stability into a single thing literally is probably not a good idea. Visibilities are also important during import resolution and affect how far things are reexported (with globs or not), while stability/deprecation is a single post-processing check not interacting with anything else. That said, the error "trying to access something unstable" is probably going to be reported in the same place as "trying to access something private" despite the differences, after resolving a path segment.
Vadim Petrochenkov at 2018-09-29 13:47:53
Note that this caused actual problems in the standard library itself, where two items that were supposedly deprecated were silently failing to trigger the deprecation warning for several years: https://github.com/rust-lang/rust/issues/82080

Would making the attribute itself error when applied to a use be easier than making this work properly? This would still be better than the current behavior of silently failing to apply the attribute.
bstrie at 2021-02-22 18:29:59
From https://github.com/rust-lang/rust/pull/83269#discussion_r597227772 :

I wonder if we could tweak things slightly so that it does work - also see #83248 (comment).

The information of which imports you went through should exist during name resolution, and we'd only have to keep track of one DefId (the "nearest" pub use to the import) for deprecation checking purposes.

bstrie at 2021-03-18 21:00:44
Hey, I'd find the ability to deprecate re-exports very useful for maintaining PyO3, so I'm interested in working on this.

Someone just needs to do this thankless job and 1) (preferable) move stability/deprecation checking to resolve phase

@petrochenkov is the above statement still true, and option (1) preferred? From a quick scan of the code it looks like that is the case. Appreciate that you previously said you're not interested in mentoring this issue. Is there a Zulip room which would be appropriate for me to ask questions about direction / implementation of this?
David Hewitt at 2022-09-23 15:11:37