Support multiple stability attributes on items #131824
Conversation
|
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred in src/librustdoc/clean/types.rs cc @camelid These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
This comment has been minimized.
This comment has been minimized.
dianne
force-pushed
the
multiple-unstables
branch
from
ebf7852
to
14b8556
Compare
|
☔ The latest upstream changes (presumably #132020) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
14b8556
to
6561424
Compare
|
☔ The latest upstream changes (presumably #132027) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
6561424
to
0a730d9
Compare
|
☔ The latest upstream changes (presumably #131985) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
0a730d9
to
86fac38
Compare
|
☔ The latest upstream changes (presumably #131349) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
86fac38
to
88e33bf
Compare
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
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. |
|
☔ The latest upstream changes (presumably #131284) made this pull request unmergeable. Please resolve the merge conflicts. |
|
The PR should explain what the semantics are of having multiple
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 |
dianne
force-pushed
the
multiple-unstables
branch
from
88e33bf
to
bc6c3b0
Compare
|
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. |
RalfJung
added
I-libs-api-nominated
|
☔ The latest upstream changes (presumably #132145) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
bc6c3b0
to
5a1fd55
Compare
|
☔ The latest upstream changes (presumably #132435) made this pull request unmergeable. Please resolve the merge conflicts. |
|
We discussed this in the libs-api meeting today and we're happy with this as proposed. Support for multiple |
Amanieu
removed
the
I-libs-api-nominated
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. 😅
Nice! I'll get to work on documenting it soon. |
|
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. |
dianne
force-pushed
the
multiple-unstables
branch
from
e393929
to
b9af36e
Compare
|
Some changes occurred to the CTFE machinery cc @rust-lang/wg-const-eval |
|
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. |
|
We changed the notification settings recently and apparently that triggers a new notification.
|
|
☔ The latest upstream changes (presumably #132831) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
b9af36e
to
4bbcf10
Compare
|
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 |
|
☔ The latest upstream changes (presumably #132954) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
from
4bbcf10
to
814ab38
Compare
I agree that the cost/benefit ratio here is too high, from the compiler maintenance point of view. |
|
☔ The latest upstream changes (presumably #132910) made this pull request unmergeable. Please resolve the merge conflicts. |
dianne
force-pushed
the
multiple-unstables
branch
2 times, most recently
from
6f28bda
to
9138a57
Compare
|
☔ The latest upstream changes (presumably #133179) made this pull request unmergeable. Please resolve the merge conflicts. |
This moves stability structs' `feature` fields into `StabilityLevel::Unstable` and `ConstStabilityLevel::Unstable`, in preparation to support multiple unstable attributes on items. Seemingly, the `feature` field isn't used with the `StabilityLevel::Stable` variant, so I haven't included it. `rustc_passes::lib_features` uses the 'feature' meta-item for 'stable' attributes, but it extracts them itself, rather than relying on `rustc_attr`.
…ions the logic for adding unstable attrs gets a bit messier when supporting multiple instances thereof. this keeps that from being duplicated in 3 places.
Translation is in an awkward position, but this provides a similar interface for both errors and soft-unstable lints, and enables the use of `DiagSymbolList` for simplifying error message construction.
This changes the text for E0544. Unfortunately, the example doesn't make much sense anymore. The way this merges stability levels together is made to work for stability-checking and rustdoc; as far as I can tell, only `rustc_passes::lib_features` needs them separate, and it extracts them itself. This includes the clarified/fixed const-unstable semantics that were previously in a different commit.
`reason` must appear at most once: it's the reason for the item being unstable, rather than a particular feature. This simplifies diagnostic formatting. `soft` must either be on all or no unstable attributes: it doesn't make sense for something to be partially soft, and allowing inconsistent softness markers would risk an item accidentally becoming properly unstable as its features stabilize.
dianne
force-pushed
the
multiple-unstables
branch
from
9138a57
to
b23f28d
Compare
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
#[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.#[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.#[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
#[unstable]attribute on an item may have areasonprovided (and likewise for#[rustc_const_unstable]and#[rustc_default_body_unstable]). At a glance, thereasonmeta-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.#[unstable]attribute on an item has asoftmarker, 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: #132544Some notes on assumptions I've made and how I've handled them:
rustc_passes::lib_featuresalso 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).#[unstable]attribute, this usesSmallVec<[_; 1]>for storage. Is this assumption reasonable? I haven't done any performance testing.StabilityLevelno longer hasCopy, 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 letStabilityLevelregainCopy).As a stopgap until Proper support for cross-crate recursive const stability checks #132541 lands, this is using aConstStabilityLevelenum for const-stability levels. Once that's merged, I should be able to move const-stability levels back to usingStabilityLevel.This doesn't update any libraries to add additional unstable attributes to items that should have them.