Tracking issue for `#[deprecated]` #29935

alexcrichton · 2015-11-19T18:37:07Z

llogiq · 2015-11-20T06:26:40Z

So should we

rename the current rustc-internal feature
extends and change the feature so it works (unstably) outside of rustc?

huonw · 2015-11-20T07:22:34Z

Renaming may help ensure there's no accidental contamination of the stable one with any new features in the internal one.

llogiq · 2015-11-20T08:25:59Z

OK, I'll see if I find the time to whip up a PR to rename #[deprecated] to #[rustc_deprecated].

petrochenkov · 2015-11-20T11:17:04Z

@llogiq

OK, I'll see if I find the time to whip up a PR to rename #[deprecated] to #[rustc_deprecated]

I'll go ahead and do it right now if you do not mind.
(I'm currently doing some work with stability anyway)

llogiq · 2015-11-20T11:53:57Z

Fine with me.

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

@llogiq

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

bluss · 2016-02-08T13:03:21Z

#[deprecated] is great, but still unstable! Can we stabilize it soon? I'm putting it to use where possible.

I am reopening this as the tracking issue should be open until it's stable.

petrochenkov · 2016-02-08T13:12:20Z

Oh, by the way, #[deprecated] on a module (or any other item) is inherited by all the child items of that module.
This behavior is reasonable and it's inherited from #[rustc_deprecated] and other stability attributes, but it was never discussed explicitly, AFAIR.
One minor drawback of this behavior is that items inside of deprecated modules can't be "undeprecated".

alexcrichton · 2016-03-11T18:04:58Z

🔔 This issue is now entering its cycle-long final comment period for stabilization in 1.9 🔔

A question to consider as part of FCP is that you can't selectively allow deprecations, only blanket allow deprecations. This is somewhat unfortunate as you frequently just want to allow usage of one deprecated API, but not necessarily all.

jonas-schievink · 2016-03-11T19:40:02Z

@alexcrichton When attributes on statements and expression are stable (and the current #[allow] logic is fixed), you could just allow a single use of a deprecated item

alexcrichton · 2016-03-11T21:32:46Z

@jonas-schievink indeed! One problem with that though is if I have widespread usage of one API in my program I'd have to tag lots of places as #[allow] :(

An example is that in the past Cargo was trying to support super old Rust versions, and one notable part of that was the deprecation of str::connect in favor of str::join, where Cargo called connect quite a bit. This ended up meaning that #[allow(deprecated)] had to be put in lots of places :(

llogiq · 2016-03-11T22:57:41Z

One partial solution is to write a non-deprecated wrapper around the deprecated API and redact usage to use the wrapper. Of course this is tedious.

huonw · 2016-04-06T11:47:31Z

A question to consider as part of FCP is that you can't selectively allow deprecations, only blanket allow deprecations. This is somewhat unfortunate as you frequently just want to allow usage of one deprecated API, but not necessarily all.

Easy targeted allows is the sticking point for me, e.g. people are able to stick an attribute at the top of a crate, rather than at every usage, or writing their own wrappers. Without that, it seems like widespread usage of #[deprecated] by library authors (a good thing!) would result in a lot of crates with #[allow(deprecated)] due to one dependency. This would dramatically weaken the utility of deprecated: any crate with that allow would get no new deprecation warnings even from crates that they did not originally need the allow for.

(For that reason, maybe we want to deprecate #[allow(deprecated)] once we have targeted allows, either removing that blanket allow functionality, or at least making it more explicit?)

bluss · 2016-04-06T11:53:25Z

I've only had to put allow(deprecated) on use lines and the actual methods where I used the deprecated items. That was pretty well scoped.

jan-hudec · 2016-04-06T15:20:34Z

Actually I would consider a better option to normally keep the warnings, but report each deprecated symbol only once. That would make it short enough to notice any new warnings while keeping it up as a reminder that something needs to be done about it.

hoodie · 2016-04-06T16:34:41Z

isn't that already the case?

alexcrichton · 2016-04-07T17:22:03Z

The libs team discussed this during triage yesterday and the decision was to stabilize.

We discussed @huonw's concern but we felt that this has been waiting long enough and the situation isn't bad enough that we should hold off stabilization.

This commit applies all stabilizations, renamings, and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long "final comment period" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes rust-lang#27719 cc rust-lang#27751 (deprecating the `Slice` bits) Closes rust-lang#27754 Closes rust-lang#27780 Closes rust-lang#27809 Closes rust-lang#27811 Closes rust-lang#27830 Closes rust-lang#28050 Closes rust-lang#29453 Closes rust-lang#29791 Closes rust-lang#29935 Closes rust-lang#30014 Closes rust-lang#30752 Closes rust-lang#31262 cc rust-lang#31398 (still need to deal with `before_exec`) Closes rust-lang#31405 Closes rust-lang#31572 Closes rust-lang#31755 Closes rust-lang#31756

std: Stabilize APIs for the 1.9 release This commit applies all stabilizations, renamings, and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long "final comment period" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes #27719 cc #27751 (deprecating the `Slice` bits) Closes #27754 Closes #27780 Closes #27809 Closes #27811 Closes #27830 Closes #28050 Closes #29453 Closes #29791 Closes #29935 Closes #30014 Closes #30752 Closes #31262 cc #31398 (still need to deal with `before_exec`) Closes #31405 Closes #31572 Closes #31755 Closes #31756

This commit applies all stabilizations, renamings, and deprecations that the library team has decided on for the upcoming 1.9 release. All tracking issues have gone through a cycle-long "final comment period" and the specific APIs stabilized/deprecated are: Stable * `std::panic` * `std::panic::catch_unwind` (renamed from `recover`) * `std::panic::resume_unwind` (renamed from `propagate`) * `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`) * `std::panic::UnwindSafe` (renamed from `RecoverSafe`) * `str::is_char_boundary` * `<*const T>::as_ref` * `<*mut T>::as_ref` * `<*mut T>::as_mut` * `AsciiExt::make_ascii_uppercase` * `AsciiExt::make_ascii_lowercase` * `char::decode_utf16` * `char::DecodeUtf16` * `char::DecodeUtf16Error` * `char::DecodeUtf16Error::unpaired_surrogate` * `BTreeSet::take` * `BTreeSet::replace` * `BTreeSet::get` * `HashSet::take` * `HashSet::replace` * `HashSet::get` * `OsString::with_capacity` * `OsString::clear` * `OsString::capacity` * `OsString::reserve` * `OsString::reserve_exact` * `OsStr::is_empty` * `OsStr::len` * `std::os::unix::thread` * `RawPthread` * `JoinHandleExt` * `JoinHandleExt::as_pthread_t` * `JoinHandleExt::into_pthread_t` * `HashSet::hasher` * `HashMap::hasher` * `CommandExt::exec` * `File::try_clone` * `SocketAddr::set_ip` * `SocketAddr::set_port` * `SocketAddrV4::set_ip` * `SocketAddrV4::set_port` * `SocketAddrV6::set_ip` * `SocketAddrV6::set_port` * `SocketAddrV6::set_flowinfo` * `SocketAddrV6::set_scope_id` * `<[T]>::copy_from_slice` * `ptr::read_volatile` * `ptr::write_volatile` * The `#[deprecated]` attribute * `OpenOptions::create_new` Deprecated * `std::raw::Slice` - use raw parts of `slice` module instead * `std::raw::Repr` - use raw parts of `slice` module instead * `str::char_range_at` - use slicing plus `chars()` plus `len_utf8` * `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8` * `str::char_at` - use slicing plus `chars()` * `str::char_at_reverse` - use slicing plus `chars().rev()` * `str::slice_shift_char` - use `chars()` plus `Chars::as_str` * `CommandExt::session_leader` - use `before_exec` instead. Closes rust-lang#27719 cc rust-lang#27751 (deprecating the `Slice` bits) Closes rust-lang#27754 Closes rust-lang#27780 Closes rust-lang#27809 Closes rust-lang#27811 Closes rust-lang#27830 Closes rust-lang#28050 Closes rust-lang#29453 Closes rust-lang#29791 Closes rust-lang#29935 Closes rust-lang#30014 Closes rust-lang#30752 Closes rust-lang#31262 cc rust-lang#31398 (still need to deal with `before_exec`) Closes rust-lang#31405 Closes rust-lang#31572 Closes rust-lang#31755 Closes rust-lang#31756

iddm · 2019-06-13T20:22:56Z

I have just deprecated a function and now whenever I invoke cargo test --doc, the code example in the doc comment for this function gives me a warning. I wonder, is there any sense in this? I would disable printing deprecation warning in the doc comments of the function which has been deprecated.

llogiq · 2019-06-14T10:25:38Z

That would quell deprecation warnings from other places, which would then fly under the radar.

The optimum solution would be to create an annotation that works as allow(deprecation) but only for deprecated items within the current module. We could then extend rustdoc to search for deprecation annotations and add this restricted allow annotation to the doctest item.

iddm · 2019-06-14T10:28:25Z

That would quell deprecation warnings from other places, which would then fly under the radar.

The optimum solution would be to create an annotation that works as allow(deprecation) but only for deprecated items within the current module. We could then extend rustdoc to search for deprecation annotations and add this restricted allow annotation to the doctest item.

Sounds legit.

alexcrichton added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Nov 19, 2015

alexcrichton mentioned this issue Nov 19, 2015

RFC: #[deprecated] for Everyone rust-lang/rfcs#1270

Merged

petrochenkov mentioned this issue Nov 20, 2015

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

Merged

bors added a commit that referenced this issue Nov 23, 2015

Auto merge of #29952 - petrochenkov:depr, r=brson

040a77f

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

petrochenkov mentioned this issue Dec 4, 2015

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

Merged

bors closed this as completed in #30206 Dec 16, 2015

bluss reopened this Feb 8, 2016

bluss added the B-unstable Blocker: Implemented in the nightly compiler and unstable. label Feb 8, 2016

bluss changed the title ~~Allow #[deprecated] outside of #[staged_api]~~ Tracking issue for #[deprecated] Feb 8, 2016

alexcrichton added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Feb 18, 2016

sfackler added the I-nominated label Mar 2, 2016

alexcrichton added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed I-nominated labels Mar 11, 2016

alexcrichton mentioned this issue Apr 7, 2016

std: Stabilize APIs for the 1.9 release #32804

Merged

bors closed this as completed in #32804 Apr 12, 2016

maciejhirsz mentioned this issue Jul 16, 2016

Deprecation warning/error with json-rust 0.9.0 maciejhirsz/json-rust#74

Closed

kvark mentioned this issue May 19, 2017

Rename Matrix2D/4D into Transform2D/3D servo/euclid#194

Merged

CasualX mentioned this issue Jan 5, 2018

Using deprecated items within the crate that deprecated them issues warnings #47219

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for `#[deprecated]` #29935

Tracking issue for `#[deprecated]` #29935

alexcrichton commented Nov 19, 2015

llogiq commented Nov 20, 2015

huonw commented Nov 20, 2015

llogiq commented Nov 20, 2015

petrochenkov commented Nov 20, 2015

llogiq commented Nov 20, 2015

bluss commented Feb 8, 2016

petrochenkov commented Feb 8, 2016

alexcrichton commented Mar 11, 2016

jonas-schievink commented Mar 11, 2016

alexcrichton commented Mar 11, 2016

llogiq commented Mar 11, 2016

huonw commented Apr 6, 2016

bluss commented Apr 6, 2016

jan-hudec commented Apr 6, 2016

hoodie commented Apr 6, 2016

alexcrichton commented Apr 7, 2016

iddm commented Jun 13, 2019

llogiq commented Jun 14, 2019

iddm commented Jun 14, 2019

Tracking issue for #[deprecated] #29935

Tracking issue for #[deprecated] #29935

Comments

alexcrichton commented Nov 19, 2015

llogiq commented Nov 20, 2015

huonw commented Nov 20, 2015

llogiq commented Nov 20, 2015

petrochenkov commented Nov 20, 2015

llogiq commented Nov 20, 2015

bluss commented Feb 8, 2016

petrochenkov commented Feb 8, 2016

alexcrichton commented Mar 11, 2016

jonas-schievink commented Mar 11, 2016

alexcrichton commented Mar 11, 2016

llogiq commented Mar 11, 2016

huonw commented Apr 6, 2016

bluss commented Apr 6, 2016

jan-hudec commented Apr 6, 2016

hoodie commented Apr 6, 2016

alexcrichton commented Apr 7, 2016

iddm commented Jun 13, 2019

llogiq commented Jun 14, 2019

iddm commented Jun 14, 2019

Tracking issue for `#[deprecated]` #29935

Tracking issue for `#[deprecated]` #29935