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.

Sign up for GitHub

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

Jump to bottom

Implement #[deprecated] attribute (RFC 1270) #30206

Merged
merged 3 commits into from
Dec 16, 2015
Merged

Implement #[deprecated] attribute (RFC 1270) #30206

merged 3 commits into from
Dec 16, 2015

Conversation

petrochenkov
Copy link
Contributor

Closes #29935

The attributes deprecated and rustc_deprecated are completely independent in this implementation and it leads to some noticeable code duplication. Representing deprecated as

Stability {
    level: Stable { since: "" },
    feature: "",
    depr: Some(Deprecation),
}

or, contrariwise, splitting rustc_deprecation from stability makes most of the duplication go away.
I can do this refactoring, but before doing it I must be sure, that further divergence of deprecated and rustc_deprecated is certainly not a goal.

cc @llogiq

@rust-highfive
Copy link
Collaborator

r? @brson

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

@llogiq
Copy link
Contributor

llogiq commented Dec 4, 2015

Great work, @petrochenkov! I think allowing the features to diverge further was the express intent of the RFC. This means we can use #[rustc_deprecation] as is and iterate on the #[deprecation] feature, e.g. adding other optional fields.

@petrochenkov
Copy link
Contributor Author

I'd prefer the standard library to migrate to #[deprecated] eventually (after its stabilization, for example), maybe with slightly stricter checks, like now. I.e. I see #[rustc_deprecated] as a temporary measure.

@brson
Copy link
Contributor

brson commented Dec 10, 2015

This patch looks quite thorough. Good work.

brson
brson reviewed Dec 10, 2015
View reviewed changes
src/librustc/middle/stability.rs
"`#[deprecated]` attribute is unstable");
fileline_help!(self.tcx.sess, attr.span(), "add #![feature(deprecated)] to \
the crate features to enable");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check should probably be in libsyntax/feature_gate.rs

@petrochenkov
Copy link
Contributor Author

Updated with comments addressed.
I've also added rustdoc support for #[deprecated]. (I intended to avoid doing this initially and merge Deprecation into Stability instead.)

@brson
Copy link
Contributor

brson commented Dec 15, 2015

@bors r+

@bors
Copy link
Contributor

bors commented Dec 15, 2015

📌 Commit 67a9784 has been approved by brson

@bors
Copy link
Contributor

bors commented Dec 16, 2015

⌛ Testing commit 67a9784 with merge ac2c5ff...

bors added a commit that referenced this pull request Dec 16, 2015
@bors
Auto merge of #30206 - petrochenkov:newdepr, r=brson
ac2c5ff 
Closes #29935

The attributes `deprecated` and `rustc_deprecated` are completely independent in this implementation and it leads to some noticeable code duplication. Representing `deprecated` as
```
Stability {
    level: Stable { since: "" },
    feature: "",
    depr: Some(Deprecation),
}
```
or, contrariwise, splitting rustc_deprecation from stability makes most of the duplication go away.
I can do this refactoring, but before doing it I must be sure, that further divergence of `deprecated` and `rustc_deprecated` is certainly not a goal.

cc @llogiq
@bors
Copy link
Contributor

bors commented Dec 16, 2015

☀️ 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

@bors bors merged commit 67a9784 into rust-lang:master Dec 16, 2015
This was referenced Dec 16, 2015
Closed
Merged
Merged
@durka
Copy link
Contributor

durka commented Dec 22, 2015

Is there a reason (heh) that this was implemented with #[deprecated(note = "...")] instead of #[deprecated(reason = "...")] as in the RFC? Should we amend the RFC to match (the rename was mentioned as an alternative but not in the main text)?

@petrochenkov
Copy link
Contributor Author

@durka

Is there a reason (heh) that this was implemented with #[deprecated(note = "...")] instead of #[deprecated(reason = "...")] as in the RFC?

Yes, by request from the RFC author, also see rust-lang/rfcs#1270 (comment)
RFC should really be amended since it's the central piece of documentation about this feature at the moment.

@durka durka mentioned this pull request Dec 22, 2015
Merged
@liigo
Copy link
Contributor

liigo commented Dec 23, 2015

I'm surprised. Implementation violate the RFC (note VS reason) intentionally without any reason, and surprised that was merged without any query. I don't oppose note (I like it), I just obey the RFC.

(This is not the first time i noticed that RFC was violated by intention. Please respect RFC! Please amend RFC first if you think there is an error.)

@llogiq
Copy link
Contributor

llogiq commented Dec 23, 2015

I'm a bit busy ATM but will push a PR to change the RFC shortly to alleviate the situation.

@llogiq
Copy link
Contributor

llogiq commented Dec 23, 2015

See RFC PR #1425

@durka
Copy link
Contributor

durka commented Dec 23, 2015

Oops, I had already submitted the same PR at rust-lang/rfcs#1423. @liigo your language is a bit stronger than necessary since this decision was essentially made in the RFC thread as it was being accepted, but just didn't make it into the text on time.

@liigo
Copy link
Contributor

liigo commented Dec 24, 2015

since this decision was essentially made in the RFC thread

I don't think so. Only three people says "note seems fine", no consensus, no confirmed by the libs (or lang) team.

When RFC 1270 was merging, Alex said:

we can always tweak minor details like naming here and there after this is merged

That is, note was not accepted yet at that time.

@llogiq
Copy link
Contributor

llogiq commented Dec 24, 2015

It isn't unusual to tweak details in the implementation after an RFC is accepted. Please forgive my cavalier attitude, but I don't think changing a field name on an unstable attribute requires the whole teams' consenus.

@petrochenkov
Copy link
Contributor Author

I've just noticed, this is not marked with "relnotes", but probably should be.

@bluss bluss added the relnotes Marks issues that should be documented in the release notes of the next release. label Jan 11, 2016
@bluss
Copy link
Member

bluss commented Jan 11, 2016

Is there a tracking issue for stabilization?

@petrochenkov petrochenkov deleted the newdepr branch September 21, 2016 19:41
@kennytm kennytm mentioned this pull request Aug 20, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@brson brson

Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@petrochenkov @rust-highfive @llogiq @brson @bors @durka @liigo @bluss