Allow deprecated_in_future lint to specify an indeterminate future deprecation date
#78381
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-libs-api
Relevant to the library API team, which will review and decide on the PR/issue.
Comments
This was referenced Oct 25, 2020
bstrie
added
the
T-libs-api
jyn514
added
the
C-enhancement
camelid
added
the
A-lint
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
Dec 16, 2020
Allow `since="TBD"` for rustc_deprecated Closes rust-lang#78381. This PR only affects `#[rustc_deprecated]`, not `#[deprecated]`, so there is no effect on any stable language feature. Likewise this PR only implements `since="TBD"`, it does not actually tag any library functions with it, so there is no effect on any stable API. Overview of changes: * `rustc_middle/stability.rs`: * change `deprecation_in_effect` function to return `false` when `since="TBD"` * tidy up the compiler output when a deprecated item has `since="TBD"` * `rustc_passes/stability.rs`: * allow `since="TBD"` to pass the sanity check for stable_version < deprecated_version * refactor the "invalid stability version" and "invalid deprecation version" error into separate errors * rustdoc: make `since="TBD"` message on a deprecated item's page match the command-line deprecation output * tests: * test rustdoc output * test that the `deprecated_in_future` lint fires when `since="TBD"` * test the new "invalid deprecation version" error message
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this issue
Jan 14, 2021
Deprecate-in-future the constants superceded by RFC 2700 Successor to rust-lang#78335, re-opened after addressing the issues tracked in rust-lang#68490. This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see rust-lang#78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future). With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see rust-lang#68490 (comment)).
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this issue
Jan 14, 2021
Deprecate-in-future the constants superceded by RFC 2700 Successor to rust-lang#78335, re-opened after addressing the issues tracked in rust-lang#68490. This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see rust-lang#78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future). With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see rust-lang#68490 (comment)).
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 21, 2021
Deprecate-in-future the constants superceded by RFC 2700 Successor to rust-lang#78335, re-opened after addressing the issues tracked in rust-lang#68490. This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see rust-lang#78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future). With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see rust-lang#68490 (comment)).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #78335 there was discussion regarding a first-class "soft deprecation" mechanism.
For background, currently the numeric constants in the primitive-shadowing std modules (e.g.
std::u8::MAX) have been superseded by associated constants (#68490). The old constants have been "soft deprecated", which is to say that their documentation suggests the new alternatives, but there is no lint or compiler warning implemented to suggest this.The obvious next step would be to deprecate these constants, but the deprecation lint is warn-by-default, and some members of the libs team are concerned that this is too minor of a change to justify warnings (outside of an edition, anyway).
There is a more gradual change that should be more palatable: the deprecated_in_future lint (#56203). This lint differs from deprecation in that it is allow-by-default rather than warn-by-default. It would allow users to opt-in to warnings (useful for, e.g., the compiler itself: #78380). Furthermore this lint has the additional benefit of being as visible in the docs as an ordinary deprecation, which is a primary concern of #68490. It's the perfect middle ground to resolve the tension here.
However, the deprecated_in_future lint is triggered by giving the usual
rustc_deprecatedattribute asincevalue in the future. For the purpose of maximum political expedience, it would be nice in this instance to not have to determine an actual specific deprecation date, and merely suggest that it will be deprecated "eventually".In particular, a release coinciding with an edition seems like a natural time to deprecate, but we won't know exactly which release that will be until much closer to the edition date. In the interim it seems a shame that such scheduling details should prevent users from opting-in to deprecation warnings.
If such a feature existed, we can imagine that it would have already naturally been employed when the documentation of
std::u8::MAXet al was originally changed to mention "soft deprecation".I propose that the
rustc_deprecatedattribute should be able to accept asincevalue of"TBD", in order to trigger the benefits of the deprecated_in_future lint without having to commit to a concrete deprecation date.The text was updated successfully, but these errors were encountered: