Remove soft_unstable

[RalfJung]

Proposal

The soft_unstable lint (rust-lang/rust#64266) was added many years ago to warn against the #[bench] attribute and later also used for RustcEncodable & RustcDecodable and for some inner attribute cleanup. For more than a year now, the lint is entirely unused in the compiler. With it comes some infrastructure in the staged_api attributes to mark library items as soft-unstable such that using them on stable triggers the lint instead of the usual hard error.

I think we should remove the lint and the concept of soft-unstable library features. It is tempting to have some common infrastructure for de-stabilizing accidentally stable features, but the problem is that the lint couples all of these features together in terms of whether the lint is warn- or deny-by-default and whether it shows up in dependencies. In practice we want to control this timeline separately for each such de-stabilization. De-stabilizations are also just not common enough to warrant having all this soft-unstable-library-feature tracking in the compiler (in the entire 10 years since Rust 1.0, to my knowledge this was used exactly once, for the rather exceptional case of RustcEncodable & RustcDecodable).

EDIT: #[bench] also involved a library item, so the soft-unstable library item concept was used twice overall.

We should, however, check in with the libs team before actually removing this.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[WaffleLapkin]

@rustbot second

[RalfJung]

@rust-lang/libs-api please let us know your thoughts on this (ideally on Zulip). Is the ability to mark library items as "soft unstable" useful enough to keep around, despite it having been used only once ever and the other issues mentioned above?

[rustbot]

The final comment period is now complete, this major change is now accepted. 🎉

As the automated representative, I want to express gratitude to the author for their work and everyone else who contributed to this major change proposal.

If you think this major change shouldn't have been accepted, feel free to remove the major-change-accepted label and reopen this issue.

Note

Further progress is now tracked over at rust-lang/rust#153572.