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

Conversation

Projects
None yet
8 participants
@petrochenkov
Contributor

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

This comment has been minimized.

Collaborator

rust-highfive commented Nov 20, 2015

r? @brson

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

@brson

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

bors commented Nov 23, 2015

📌 Commit a613059 has been approved by brson

@brson brson referenced this pull request Nov 23, 2015

Closed

Remove `#[staged_api]` #30008

@bors

This comment has been minimized.

Contributor

bors commented Nov 23, 2015

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

bors added a commit that referenced this pull request Nov 23, 2015

Auto merge of #29952 - petrochenkov:depr, r=brson
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

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@diafero

This comment has been minimized.

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

This comment has been minimized.

Contributor

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