introduce implied_by in #[unstable] attribute by davidtwco · Pull Request #99212 · rust-lang/rust (original) (raw)

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_by meta-item can be added to #[unstable] to indicate which now-stable feature was used previously.

error: the feature `foo` has been partially stabilized since 1.62.0 and is succeeded by the feature `foobar`
  --> $DIR/stability-attribute-implies-using-unstable.rs:3:12
   |
LL | #![feature(foo)]
   |            ^^^
   |
note: the lint level is defined here
  --> $DIR/stability-attribute-implies-using-stable.rs:2:9
   |
LL | #![deny(stable_features)]
   |         ^^^^^^^^^^^^^^^
help: if you are using features which are still unstable, change to using `foobar`
   |
LL | #![feature(foobar)]
   |            ~~~~~~
help: if you are using features which are now stable, remove this line
   |
LL - #![feature(foo)]
   |

When a #![feature(..)] attribute still exists for the now-stable attribute, then there this has two effects:

In the Zulip discussion, this was envisioned as implies on #[stable] but I went with implied_by on #[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:

/// This mapping is necessary unless both the `#[stable]` and `#[unstable]` attributes should
/// specify their implications (both `implies` and `implied_by`). If only one of the two
/// attributes do (as in the current implementation, `implied_by` in `#[unstable]`), then this
/// mapping is necessary for diagnostics. When a "unnecessary feature attribute" error is
/// reported, only the `#[stable]` attribute information is available, so the map is necessary
/// to know that the feature implies another feature. If it were reversed, and the `#[stable]`
/// attribute had an `implies` meta item, then a map would be necessary when avoiding a "use of
/// unstable feature" error for a feature that was implied.

I also change some comments to documentation comments in the compiler, add a helper for going from a Span to a Span for the entire line, and fix a incorrect part of the pre-existing stability attribute diagnostics.

cc @yaahc