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

Rename #[deprecated] to #[rustc_deprecated] #29952

Merged
merged 1 commit into from Nov 23, 2015
Merged

Conversation

@petrochenkov
Copy link
Contributor

@petrochenkov petrochenkov commented Nov 20, 2015

Part of #29935

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

@rust-highfive
Copy link
Collaborator

@rust-highfive rust-highfive commented Nov 20, 2015

r? @brson

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

@brson
Copy link
Contributor

@brson brson commented Nov 20, 2015

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
Copy link
Member

@alexcrichton alexcrichton commented Nov 20, 2015

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
Copy link
Member

@sfackler sfackler commented Nov 20, 2015

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
Copy link
Contributor

@llogiq llogiq commented Nov 21, 2015

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
Copy link
Contributor

@brson brson commented Nov 23, 2015

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

@bors r+

@bors
Copy link
Contributor

@bors bors commented Nov 23, 2015

📌 Commit a613059 has been approved by brson

@brson brson mentioned this pull request Nov 23, 2015
@bors
Copy link
Contributor

@bors bors commented Nov 23, 2015

Testing commit a613059 with merge 040a77f...

bors added a commit that referenced this pull request Nov 23, 2015
Part of #29935

The deprecation lint is still called "deprecated", so people can continue using `#[allow(deprecated)]` and similar things.
@bors bors merged commit a613059 into rust-lang:master Nov 23, 2015
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@diafero
Copy link

@diafero diafero commented Dec 1, 2015

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
Copy link
Contributor

@llogiq llogiq commented Dec 1, 2015

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).

@petrochenkov petrochenkov deleted the petrochenkov:depr branch Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants