Allow deprecating a re-export

[seanmonstar]

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

[steveklabnik]

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?

[joshtriplett]

I'd like to see this; deprecated should work on any declaration.

[Centril]

I agree with @joshtriplett.

[eddyb]

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

[petrochenkov]

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.

[petrochenkov]

Same issue - #23937.

[eddyb]

@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.

[petrochenkov]

@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.

[bstrie]

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: #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]

From #83269 (comment) :

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.