Clean out deprecated functions and syntax #14360
Conversation
|
How long should functions remain deprecated before it's ok to remove them? I didn't realize it was so recent, but all the rev-iter stuff was only deprecated 1 month ago. |
| fn choose_option<'a, T>(&mut self, values: &'a [T]) -> Option<&'a T> { | ||
| self.choose(values) | ||
| } | ||
|
|
There was a problem hiding this comment.
Too early to remove this, it just got deprecated.
There was a problem hiding this comment.
Oops, I thought this was deprecated in the same batch as shuffle, reverted.
|
When did we release rust 0.10? We shouldn't remove anything deprecated since then (unless it's something that was added since then as well). |
|
There is currently no hard deadline before which something cannot be removed. |
|
As for the syntax stuff, I'm all for removing all the obsolete syntax. 2 questions about it though:
|
|
Wasn't libdebug added by mistake to the first commit? |
That's one way to approach this, but we also barely place any meaning on releases right now.
Looks like it can move to the reserved category
The tilde parts are still obsolete (just a week or so old). |
|
Oops, thanks for pointing that out @Sawyer47 |
Right, but we didn't obsolete |
|
I guess we didn't start actually using Given that, I suppose it's ok to go ahead and remove this stuff. We're also going to have to remove all deprecations before minting 1.0 anyway, so it's not like people can expect to go from point-release to point-release and get proper deprecations (which is to say, anyone moving from whatever our final point-release is to 1.0 will not get any deprecations anyway). And since your goal here is to remove warnings, while I'd like to see |
|
Unless you think we have reason to keep it, we can probably remove |
|
Removed |
All of these features have been obsolete since February 2014, where most have been obsolete since 2013. There shouldn't be any more need to keep around the parser hacks after this length of time.
These have all been deprecated for awhile now, so it's likely time to start removing them.
) Adds an internal lint to check for `#[derive(serde::Deserialize)]` without [`#[serde(deny_unknown_fields)]`](https://serde.rs/container-attrs.html#deny_unknown_fields). Today, if you run Clippy with the following clippy.toml, Clippy will produce a warning, but there will be no accompanying note: ```toml # In the following configuration, "recommendation" should be "reason" or "replacement". disallowed-macros = [ { path = "std::panic", recommendation = "return a `std::result::Result::Error` instead" }, ] ``` ```sh $ cargo clippy Checking a v0.1.0 (/home/smoelius/tmp/a) warning: use of a disallowed macro `std::panic` --> src/lib.rs:2:5 | 2 | panic!(); | ^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#disallowed_macros = note: `#[warn(clippy::disallowed_macros)]` on by default ``` The underlying problem is: the enum that derives `serde::Deserialize` ([`DisallowedPathEnum`](https://github.com/rust-lang/rust-clippy/blob/81643e297cf44ce3c7648b8443fc4d6592fa81eb/clippy_config/src/types.rs#L47)) does not have the attribute `#[serde(deny_unknown_fields)]`. This lint identifies such problems by checking trait `impl`s. An alternative I considered was to walk `clippy_config::conf::Conf` directly. However, that would not catch the `DisallowedPathEnum` case because it [is not used in `Conf` directly](https://github.com/rust-lang/rust-clippy/blob/81643e297cf44ce3c7648b8443fc4d6592fa81eb/clippy_config/src/types.rs#L31). Just to be clear, no one asked for this. So I hope the maintainers do not mind. changelog: none
These have all been deprecated for awhile now, so it's likely time to start removing them.