-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename #[deprecated] to #[rustc_deprecated] #29952
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
It's not strictly necessary to do this - having two modes is exactly why we added |
Yeah I was also under the impression that we'd just change the meaning of |
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. |
Yeah, this is in preparation of the public |
If we do this then let's remember to add validation that crates don't mix the two. @bors r+ |
📌 Commit a613059 has been approved by |
Part of #29935 The deprecation lint is still called "deprecated", so people can continue using `#[allow(deprecated)]` and similar things.
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? |
One difference is that the rustc deprecation requires a stability attribute, and I suggested renaming |
Part of #29935
The deprecation lint is still called "deprecated", so people can continue using
#[allow(deprecated)]
and similar things.