Tracking Issue for #![feature(deprecated_suggestion)]

[jhpratt]

Feature gate: #![feature(deprecated_suggestion)]

This is a tracking issue for suggested replacements on deprecations. This has been used as part of the #[rustc_deprecated] attribute since 2019-01-31. The suggestions are machine-applicable, in that cargo fix is capable of making the replacement without further user intervention. As such, the suggestion must be valid Rust (though this is not enforced).

Public API

#![feature(deprecated_suggestion)]

struct Foo;

impl Foo {
    #[deprecated(suggestion = "baz")]
    fn bar() {}
    fn baz() {}
}

Steps / History

• Implementation:
  • for #[rustc_deprecated] in Add suggestions to deprecation lints #58002 (merged 2019-01-31)
  • for #[deprecated] in Merge #[deprecated] and #[rustc_deprecated] #94635 (merged 2022-03-10)
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[tgross35]

Are there any blockers to stabilizing at least the attribute? It seems like cargo fix works fine with it and the messages seem good.

[jhpratt]

Not sure what you mean by "at least the attribute", as that's literally the entire feature. But there are no blockers unless T-libs-api would like an ACP/RFC for this. It's been used as part of the standard library for 4+ years.

[tgross35]

Is suggestion enforcement validity desired? It would be a nice sanity check.

#![allow(unused)]
#![feature(deprecated_suggestion)]

struct Foo;

impl Foo {
    #[deprecated(suggestion = "new_foo")]
    fn new() -> Foo { todo!() }
    #[deprecated(suggestion = "some invalid path")]
    fn bar() {}
    fn baz() {}
}

fn new_foo() -> Foo { todo!() }

fn main() {
    // Suggests `Foo::new_foo();` which doesn't exist
    Foo::new();
    // Suggests invalid `Foo::some invalid path();`
    Foo::bar();
}

Maybe unquoted identifiers could be verified (must be brought into scope) but quoted string literals could be suggested as-is, if the current behavior is desirable for some reason (which is what I meant by at least the attribute).

[jhpratt]

It might be worth looking into whether the resulting code could be verified. It may be a fair amount of effort.

[workingjubilee]

While reviewing #113365 it became at least somewhat apparent that suggestions like these make a lot of our existing notes, which don't add meaningful context, but are just manual suggestions, redundant. It would be nice to trim out the notes!

...except doing so triggers error E0543? That seems weird.

[Nemo157]

That error is part of staged_api, it could be updated to check for either note or suggestion.

[workingjubilee]

Question: Do we want suggestions to be applied via rustfix that may be valid Rust but fail to typecheck due to a signature change? Several of the deprecations were due to that reason.

[madsmtm]

A concern: I don't think the suggestion shows up in rustdoc? And maybe rustdoc should be able to generate a link to the new functionality automatically, though I'm unsure how it would know how to?

[SamB]

Question: Do we want suggestions to be applied via rustfix that may be valid Rust but fail to typecheck due to a signature change?

Worse: what if the arguments got shuffled but still typecheck? The name suggestion doesn't do a great job of communicating the possible danger.

[workingjubilee]

Oh yeah, I can just imagine the nightmare that is a library with 2+ lerp functions and deprecated(suggestion) there...

[jhpratt]

Right now, the only thing this feature is useful for is simple renaming of methods. Anything else it cannot handle.

[lolbinarycat]

Worse: what if the arguments got shuffled but still typecheck? The name suggestion doesn't do a great job of communicating the possible danger.

perhaps renamed_to or alias_of would be better?