Remove or unstabilize all deprecated items in 1.0.0

[SimonSapin]

Previously: http://internals.rust-lang.org/t/remove-or-unstabilize-all-deprecated-items-in-1-0-0/1945

Per SemVer, major releases are the only time when we get to remove stuff. If 1.0.0 final contains any #[deprecated] item, we’ll be stuck with them until 2.0 (which hopefully will be in a very long time!)

Proposal: Make sure that all #[deprecated] items in 1.0.0 are also marked #[unstable]. This will effectively make them unavailable in beta and release builds, meaning we can remove them in some future 1.x release without breaking backward-compatibility. In terms of release process, this means back-porting a patch to beta. Then a new beta pre-release might be good.

Alternative: remove deprecated items entirely.

CC @brson

[bstrie]

Figuring that removing deprecated things is worth such a late-stage nomination.

[aturon]

@alexcrichton has been planning a patch to remove all deprecated items before 1.0.

[alexcrichton]

This was completed in #24636 which is now merged.

[SimonSapin]

I found a few that feel through the cracks and are still #[deprecated] and #[stable]:

• std::fs::soft_link
• f64::is_positive and f64::is_negative (inherent methods)

[alexcrichton]

The goal of that PR was to remove all deprecated items that were slated for deletion before 1.0. The soft_link method was deprecated very recently and will make its way into 1.0 (at virtually no overhead). The f64::is_{positive,negative} methods were also deprecated very very recently and don't necessarily warrant a breaking change.

[SimonSapin]

So it is a decision to keep them in 1.0 and be stuck with them “forever”? (Really until 2.0, but in a way not making a 2.0 for a very long time is a sign of success.)

[alexcrichton]

It's a fact of life that we're going to grow deprecated functions over time, so we need to be comfortable with it no matter what. "Being stuck" with these functions has very little overhead to us as the remaining ones are all minor renamings basically and the compiler/tests don't depend on them at all (unlike the old std::num traits).

[SimonSapin]

Alright, fair enough. Thanks for #24636!