introduce implied_by in #[unstable] attribute#99212
Merged
bors merged 6 commits intorust-lang:masterfrom Jul 20, 2022
Merged
Conversation
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.
Requested by the library team on Zulip.
If part of a feature is stabilized and a new feature is added for the remaining parts, then the
implied_bymeta-item can be added to#[unstable]to indicate which now-stable feature was used previously.When a
#![feature(..)]attribute still exists for the now-stable attribute, then there this has two effects:#![feature(..)]is removed or updated to the new feature).In the Zulip discussion, this was envisioned as
implieson#[stable]but I went withimplied_byon#[unstable]because it means that only the unstable attribute needs to be changed in future, not the new stable attribute, which seems less error-prone. It also isn't particularly feasible for me to detect whether items from the implied feature are used and then only suggest updating or removing the#![feature(..)]as appropriate, so I always do both.There's some new information in the cross-crate metadata as a result of this change, that's a little unfortunate, but without requiring that the
#[unstable]and#[stable]attributes both contain the implication information, it's necessary:I also change some comments to documentation comments in the compiler, add a helper for going from a
Spanto aSpanfor the entire line, and fix a incorrect part of the pre-existing stability attribute diagnostics.cc @yaahc