Support multiple stability attributes on items #131824
Open
+1,694
−1,063
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a refactor for supporting 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.
…els" errors this makes things a little cleaner. since multiple stability levels are allowed, I think it makes sense too.
An item is unstable if it has any unstable attributes, to make it easier to track which features library items depended on as they stabilize. 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.
…e library feature `feature`" This is consistent with all other diagnostics I could find containing features and enables the use of `DiagSymbolList` for generalizing diagnostics for unstable library features to multiple features.
|
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.
- only emits one error/lint (instead of one per missing feature) per usage of unstable and body-unstable items - only emits one future-name-collision lint (instead of one per missing feature) for unstable trait items - makes diagnostics for unstable, soft-unstable, const-unstable, and body-unstable library features translatable, using common subdiagnostic structs. - adds notes with features, reasons, and issue links to const-unstability errors - adds notes with issue links to soft_unstable lints - on nightly, adds `#![feature]` crate attr help to soft_unstable lints - on nightly, adds compiler-upgrade-suggestion notes to const-unstable and soft_unstable diagnostics
At least one test relies on this behavior, so I think the description is still correct.
dianne
force-pushed
the
multiple-unstables
branch
from
ebf7852
to
14b8556
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #94770
Based on #94988
I have some notes I'd like input on, in case they're messy or contentious. I tried to isolate some of these into their own commits, so see those for more info (sorry some of the commits are still giant! stability attributes seem to be used in a lot of places).
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 if attribute handling is reworked to be more unified in the future, this may need further adjustment (but hopefully not too much).#[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 rewordE0544this way).E0544(multiple stability levels). Should the error code be different now, or is reusing the same one okay?rustc_passes::lib_featurescatches instances of the same feature being given different stability levels or stabilization versions, so the only error it uniquely catches is when the same stability level is given multiple times (potentially with different reasons, issue numbers,implied_bys, orrustc_allowed_through_unstable_moduless).#[unstable]attribute, this usesSmallVec<[_; 1]>for storage. Is this assumption sound? I haven't done any performance testing.feature_err_issueis no longer used for library features. I've left it for now sincefeature_warn_issueis in a similar state.report_unstableandsoft_unstablecould now take a crate-level attribute injection span to letcheck_optional_stabilityprovide that when possible for suggestions on nightly. At the moment it doesn't, since it'd be even more test stderr updates (including a new error emitted fromui-fulldeps/hash-stable-is-unstable.rssince it wouldn't get de-duplicated).StabilityLevelno longer hasCopy, stability structs are now arena-allocated. I'm not sure what the performance implications are. I'm sure you could get away with putting less in the arena by doing something more complicated, if it's an issue.This doesn't update any libraries to add additional unstable attributes to items that should have them.