track renamed and removed library feature gates

[jyn514]

Code

#![feature(stdsimd)]

fn main() {
    unsafe { core::arch::x86_64::_xbegin(); }
}

Current output

Compiling playground v0.0.1 (/playground)
error[E0658]: use of unstable library feature `stdarch_x86_rtm`
 --> src/main.rs:4:14
  |
4 |     unsafe { core::arch::x86_64::_xbegin(); }
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #111138 <https://github.com/rust-lang/rust/issues/111138> for more information
  = help: add `#![feature(stdarch_x86_rtm)]` to the crate attributes to enable
  = note: this compiler was built on 2025-05-25; consider upgrading it if it is out of date

error[E0635]: unknown feature `stdsimd`
 --> src/main.rs:1:12
  |
1 | #![feature(stdsimd)]
  |            ^^^^^^^

Some errors have detailed explanations: E0635, E0658.
For more information about an error, try `rustc --explain E0635`.
error: could not compile `playground` (bin "playground") due to 2 previous errors

Desired output

error[E0557]: feature has been removed
 --> src/main.rs:1:12
  |
1 | #![feature(stdsimd)]
  |            ^^^^^^^ feature has been removed
  |
  = note: removed in 1.78 (you are currently using 1.89-nightly)
  = note: this feature has been split into many smaller features; see <https://github.com/rust-lang/rust/issues/27731#issuecomment-1937538034> for an exhaustive list

Rationale and extra context

we have something like this for lang features, whose removal we explicitly track:

error[E0557]: feature has been removed
 --> src/main.rs:3:12
  |
3 | #![feature(external_doc)]
  |            ^^^^^^^^^^^^ feature has been removed
  |
  = note: use #[doc = include_str!("filename")] instead, which handles macro invocations

but there is no way to track this for libs features, which leads to unnecessarily confusing errors. it would be nice if we could help people out more here, especially since the people seeing this error are likely not the crate authors but just people who happen to be using a nightly toolchain.

Other cases

Rust Version

1.89.0-nightly

(2025-05-25 283db70ace62a0ae704a)

Anything else?

No response

[jyn514]

this needs some api design. the current API looks like this: #[unstable(feature = "...", reason = "...", issue = "...")]. we can support renamed features by adding a unstable(alias = "OLD_NAME") meta word. removed features are slightly trickier - i think we could add a crate-attribute that looks like #![unstable_removed(feature = "...", reason = "...", issue = "...", since = "...")]? the name is ugly but the basic idea should work.

cc @rust-lang/libs-api, this mostly affects you.

[xizheyin]

How difficult is this problem, I can assist with it.

[jyn514]

i expect the code to not be too bad; it's mostly the api that needs design. but all this stuff is super unstable anyway so i think it's fine to add something that works for now and we can go back and do api design later.

the existing parsing lives around

rust/compiler/rustc_attr_parsing/src/attributes/stability.rs

Lines 290 to 292 in 30721b0

	// Read the content of a `unstable`/`rustc_const_unstable`/`rustc_default_body_unstable`
	/// attribute, and return the feature name and its stability information.
	pub(crate) fn parse_unstability(

. you'll also have to add parsing for the new unstable_removed attribute; #![recursion_limit] is a crate-level attribute that isn't too complicated, you could use that as an example for your new code.

@rustbot label E-medium E-mentor E-help-wanted

[xizheyin]

@rustbot claim