Support multiple stability attributes on items

[dianne]

Motivation

Many unstable library items require the stabilization of multiple features before they can be stabilized. By allowing them to be annotated with multiple #[unstable] attributes, this prevents their accidental stabilization when some of those features are stabilized, and helps mitigate upgrade pains for unstable toolchain users.

New stability attribute semantics

• If any #[unstable] attribute is present on an item, it is unstable. Likewise, any #[rustc_const_unstable] marks an item as const-unstable, and any #[rustc_default_body_unstable] marks it as default body-unstable.
• In order to use an unstable item, all feature gates specified by its #[unstable] attributes must be enabled. Conceptually, this is because it depends on multiple unstable features. Practically, this also means nightly toolchain users are less likely to need to replace one unstable feature gate with another in their crate-level attributes.
• Multiple #[stable] attributes may be present. The stabilization version of an item is the most recent stabilization version in present #[stable] attributes. Likewise, #[stable] attributes may be present on an unstable item. This simplifies macros that can apply stability attributes to items.

This is documented in rust-lang/rustc-dev-guide#2128.

New syntactic constraints

• As a sanity check, an item is not allowed to have multiple stability attributes for the same feature.
• At most one #[unstable] attribute on an item may have a reason provided (and likewise for #[rustc_const_unstable] and #[rustc_default_body_unstable]). At a glance, the reason meta-item was used to describe the reason for an item being unstable, rather than an individual feature it depends on. Enforcing this makes the diagnostic formatting much cleaner.
• If any #[unstable] attribute on an item has a soft marker, it must be present on all #[unstable] attributes on that item. Items can't be partially soft-unstable, and this helps prevent accidentally making a soft-unstable item unusable on stable when stabilizing one of the features it requires.

Fixes #94770

Based on #94988

PR for a diagnostic formatting change this uses: #132544

Some notes on assumptions I've made and how I've handled them:

• Stability structs are specialized to how they're used for stability checking and rustdoc. rustc_passes::lib_features also reads stability attributes, but it parses them itself. I considered it out of the scope of this PR refactor that too, but once attribute handling is reworked to be more unified in the future, this may need further adjustment (but hopefully not too much).
• Under the assumption that most library items will still have at most one #[unstable] attribute, this uses SmallVec<[_; 1]> for storage. Is this assumption reasonable? I haven't done any performance testing.
• Since StabilityLevel no longer has Copy, stability structs are now arena-allocated; that was the simplest fix. I'm not sure what the performance implications are. If it's an issue, I can try try making it only allocate for multiple unstable features (which would also let StabilityLevel regain Copy).
• As a stopgap until Proper support for cross-crate recursive const stability checks #132541 lands, this is using a ConstStabilityLevel enum for const-stability levels. Once that's merged, I should be able to move const-stability levels back to using StabilityLevel.

This doesn't update any libraries to add additional unstable attributes to items that should have them.

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[bors]

☔ The latest upstream changes (presumably #132020) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #132027) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #131985) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #131349) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[dianne]

cc @RalfJung @compiler-errors This rebase was pretty substantial and required some minor refactors. Would either of you mind giving the const-stability parts a look to make sure they make sense and don't go against planned future changes?

cc @rust-lang/libs-api I realize I should probably ping here as well. Does the design supporting a mix of unstable/stable attributes sound good? I'll try documenting it in the dev guide and std dev guide once that's finalized.

[bors]

☔ The latest upstream changes (presumably #131284) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

The PR should explain what the semantics are of having multiple unstable attributes. Do all gates need to be active to use the feature, or only some?

This supports multiple #[stable] attributes, and a mix of #[stable] and #[unstable], in case that's helpful for tracking which features library items depended on as they stabilize (and because it's less difficult to reword E0544 this way).

That sounds really strange. What is the semantics of this? And what is the point?

[dianne]

The PR should explain what the semantics are of having multiple unstable attributes. Do all gates need to be active to use the feature, or only some?

This supports multiple #[stable] attributes, and a mix of #[stable] and #[unstable], in case that's helpful for tracking which features library items depended on as they stabilize (and because it's less difficult to reword E0544 this way).

That sounds really strange. What is the semantics of this? And what is the point?

I've updated the PR description to address this. To your second point, I'm working off of this specification. Treating it as a matter of preference, I decided to implement it both with and without support for multiple #[stable] attributes in separate commits so that I'd have an implementation to point to before asking which approach is nicer. I'll work on addressing your review comments shortly. Thank you for giving this a look!

[RalfJung]

The updated PR description is great, thanks. :)

Personally I don't think multiple stable attributes, or both stable and unstable, are worth it. But let's see what t-libs-api thinks.

[bors]

☔ The latest upstream changes (presumably #132145) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #132435) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

We discussed this in the libs-api meeting today and we're happy with this as proposed. Support for multiple stable attribute was somewhat controversial but in the end we felt that it would be useful in macros which apply a mix of stability attributes to many items.

[dianne]

Whoever happens to merge their changes first will force the other to retrofit their changes onto it haha, but with some luck for you, that'll be me who has to do the retrofitting :3

I've been wondering about this. My one hope if I do the rebase is that the attribute rework will make this cleaner in the end. 😅

We discussed this in the libs-api meeting today and we're happy with this as proposed.

Nice! I'll get to work on documenting it soon.

[jdonszelmann]

It probably will, the reason it's annoying is that in my local version, builtins.rs is simply gone. It's split up into files for all the different attributes that are processed there. So we'll just have to find the parts that have to move, should be doable.

[rustbot]

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

[dianne]

Is that a new notification? Unless I made a mistake, I think all I did was resolve the merge conflict straightforwardly, so see the above discussion for how this touches the CTFE machinery.

[RalfJung]

We changed the notification settings recently and apparently that triggers a new notification.

[bors]

☔ The latest upstream changes (presumably #132831) made this pull request unmergeable. Please resolve the merge conflicts.

[dianne]

I did some cleanup to the diagnostic formatting and commit history. Now only the tests for stability attribute sanity (and the tests I added) have diffs. Hopefully it will be more digestible now, and easier to split apart if needed. Once changes to attribute handling and/or const-stability checks land it should hopefully be able to be cleaned up some more.

[bors]

☔ The latest upstream changes (presumably #132954) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

The updated PR description is great, thanks. :)

Personally I don't think multiple stable attributes, or both stable and unstable, are worth it. But let's see what t-libs-api thinks.

I agree that the cost/benefit ratio here is too high, from the compiler maintenance point of view.
It's not even a user facing feature, just a minor convenience for the library people.

[bors]

☔ The latest upstream changes (presumably #132910) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #133179) made this pull request unmergeable. Please resolve the merge conflicts.