Tracking issue for RFC 2397, "#[do_not_recommend]"

[Centril]

This is a tracking issue for the RFC "Introduce #[do_not_recommend] to control errors for trait impls" (rust-lang/rfcs#2397).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• What other names could we go with besides #[do_not_recommend]? (See RFC for some suggestions)

implementation history:

• Actually use the #[do_not_recommend] attribute if present #124708
• Refactor #[diagnostic::do_not_recommend] support #125717
• Move #[do_not_recommend] to the #[diagnostic] namespace #125326
• Allows #[diagnostic::do_not_recommend] to supress trait impls in suggestions as well #127598

[nagisa]

Minor question. Presuming we implement this, and later change diagnostics in ways that make this attribute unnecessary/harmful, what would the plan of action be then?

Does this attribute essentially encode some particular format of these specific errors?

[Centril]

@nagisa in that hypothetical situation, deprecate the attribute perhaps?

[scottmcm]

This came up in T-lang's backlog bonanza today. With no progress on this for years, it's not clear to us that this is still the right way forward here.

@estebank, do you have any thoughts on this one? Perhaps it would be better rolled into the idea you brought up in https://internals.rust-lang.org/t/stable-diagnostic-affecting-attribute-with-unstable-api/16368?u=scottmcm?