Skip to content
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

Add support for #[deprecated] attribute #723

Closed
brson opened this issue Jul 21, 2011 · 15 comments
Closed

Add support for #[deprecated] attribute #723

brson opened this issue Jul 21, 2011 · 15 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Jul 21, 2011

Usage of items tagged with #[deprecated] should generate a warning at compile time. To make this really work correctly we'll need to write item attributes to the crate metadata.

@ghost ghost assigned brson Mar 15, 2012
@eholk
Copy link
Contributor

eholk commented Jul 25, 2012

I was just thinking this would be a good idea. Would there also be a way to mark entire modules as deprecated?

@ghost ghost assigned graydon Sep 13, 2012
@graydon
Copy link
Contributor

graydon commented Sep 13, 2012

Yes. It should also take arguments that explain the deprecation and/or point to a symbol to use instead.

@brson
Copy link
Contributor Author

brson commented Sep 13, 2012

I think this is unblocked and we do write attributes to item metadata now.

@brendanzab
Copy link
Member

It'd be great if tagged items would also show up in generated documentation. D does a great job of this, highlighting the feature in red, giving a date on which the item will be dropped and pointing to an alternative item that should be used instead.

Example:

deprecated alias FormatError;
Deprecated. It will be removed In January 2013. Please use FormatException instead.

This kind of metadata could even show up in the warning at compile time. It'd be very useful for quickly updating old code.

@jesse99
Copy link
Contributor

jesse99 commented Dec 22, 2012

Also need to update the reference manual.

@pnkfelix
Copy link
Member

Not critical for 0.6; de-milestoning

@pnkfelix
Copy link
Member

(also, from looking at #4643, it sounds like this feature was backed out; not sure if that issue needs to be reopened.)

@graydon
Copy link
Contributor

graydon commented May 1, 2013

nominating for backwards compatible. not strictly needed but seems like it'd be helpful.

@brson
Copy link
Contributor Author

brson commented May 30, 2013

cc #6508

@graydon
Copy link
Contributor

graydon commented May 30, 2013

accepted for backwards-compatible milestone

@brendanzab
Copy link
Member

This would be very useful for cleaning up std::vec and std::str.

@brson
Copy link
Contributor Author

brson commented Jun 9, 2013

Per #6875 I want support for at least #[deprecated], #[experimental], #[unstable], #[stable], and maybe eventually #[frozen] and #[locked].

@emberian
Copy link
Member

Once the attributes are supported, it will be easy to use with rustdoc_ng

@emberian
Copy link
Member

#8125

rustdoc_ng outputs attributes in the JSON, it will be trivial for any frontend to use them for documentation, even if rustc doesn't warn/error on it.

@Seldaek

@huonw
Copy link
Member

huonw commented Sep 3, 2013

Basic implementation landed in #8921, subsumed by #6875 and its satellite bugs. Closing.

@huonw huonw closed this as completed Sep 3, 2013
pdietl pushed a commit to pdietl/rust that referenced this issue Apr 23, 2020
ZuseZ4 pushed a commit to EnzymeAD/rust that referenced this issue Mar 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants