Rename #[deprecated] to #[rustc_deprecated]

[petrochenkov]

Part of #29935

The deprecation lint is still called "deprecated", so people can continue using #[allow(deprecated)] and similar things.

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[brson]

It's not strictly necessary to do this - having two modes is exactly why we added #[staged_api]. Interested in hearing what others think. cc @rust-lang/libs.

[alexcrichton]

Yeah I was also under the impression that we'd just change the meaning of #[deprecated] depending on whether #[staged_api] was present or not.

[sfackler]

I'd kind of prefer this, since the semantics of the staged_api deprecated and the public deprecated do not exactly match and will probably diverge more in the future. This'll help prevent people emulating what the std lib does and getting confused when it doesn't work in their own code.

[llogiq]

Yeah, this is in preparation of the public #[deprecated] implementation to ensure both implementations don't interfere with each other. @brson Yes, it's not strictly necessary, but it'll remove the risk of interference while allowing us to use both features within one codebase, should we decide to migrate (parts of) rustc to the public feature.

[brson]

If we do this then let's remember to add validation that crates don't mix the two.

@bors r+

[bors]

📌 Commit a613059 has been approved by brson

[bors]

⌛️ Testing commit a613059 with merge 040a77f...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[diafero]

since the semantics of the staged_api deprecated and the public deprecated do not exactly match and will probably diverge more in the future.

I had a look at the RFC and the tracking issue, but was unable to find out what this statement is based on. Superficially, the two attributes seem very similar, even having the same arguments. What's the difference?

[llogiq]

One difference is that the rustc deprecation requires a stability attribute, and I suggested renaming reason to note as that matches actual usage better. (The RFC was merged before incorporating that suggestion).