Skip to content

track the version and PR in which a nightly feature was removed #141619

Closed

Description

@jyn514

Code

#![feature(external_doc)]
#![doc(include("README.md"))]

Current output

error[E0557]: feature has been removed
 --> src/lib.rs:1:12
  |
1 | #![feature(external_doc)]
  |            ^^^^^^^^^^^^ feature has been removed
  |
  = note: use #[doc = include_str!("filename")] instead, which handles macro invocations

error: unknown `doc` attribute `include`
 --> src/lib.rs:2:8
  |
2 | #![doc(include("README.md"))]
  |        ^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(invalid_doc_attributes)]` on by default

Desired output

error[E0557]: feature has been removed
 --> src/lib.rs:1:12
  |
1 | #![feature(external_doc)]
  |            ^^^^^^^^^^^^ feature has been removed
  |
  = note: removed in 1.54 (you are using 1.89-nightly); see <https://github.com/rust-lang/rust/pull/85457>
  = note: use #[doc = include_str!("filename")] instead, which handles macro invocations

Rationale and extra context

this makes it more clear what is going on, and also gives people enough breadcrumbs to find more information. right now it is very hard to find info about removed features without trawling through the code (it took me about 15 minutes just now, and i am both the person who removed this feature and the one who stabilized its replacement).

saying the version also makes it more clear that "removed" is specifically about versions, and tells the person compiling the code that using an older toolchain will likely work. this matters because the person seeing this error is likely not the one who wrote the code, and possibly knows very little about rust's stability policy.

Other cases

Rust Version

1.89.0-nightly

(2025-05-25 283db70ace62a0ae704a)

Anything else?

No response

Activity

  1. added
    A-diagnosticsArea: Messages for errors, warnings, and lints
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on May 26, 2025
  2. jyn514 commented on May 27, 2025

    @jyn514
    MemberAuthor

    oh neat, we already track version:

    (removed, abi_amdgpu_kernel, "1.77.0", Some(51575), None),

    that makes the version part of this quite simple, and we can add pr info later.

    mentoring instructions: in

    // If the enabled feature has been removed, issue an error.
    if let Some(f) = REMOVED_LANG_FEATURES.iter().find(|f| name == f.feature.name) {
    sess.dcx().emit_err(FeatureRemoved {
    span: mi.span(),
    reason: f.reason.map(|reason| FeatureRemovedReason { reason }),
    });
    continue;
    }
    , add a note about when the feature was removed.

    @rustbot label E-help-wanted E-easy

  3. added
    E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
    E-help-wantedCall for participation: Help is requested to fix this issue.
    on May 27, 2025
  4. xizheyin commented on May 27, 2025

    @xizheyin
    Member

    @rustbot claim

  5. xizheyin commented on May 27, 2025

    @xizheyin
    Member

    For removed feature, the version may be not accurate, is this some kind of historical problem?

    pub struct Feature {
    pub name: Symbol,
    /// For unstable features: the version the feature was added in.
    /// For accepted features: the version the feature got stabilized in.
    /// For removed features we are inconsistent; sometimes this is the
    /// version it got added, sometimes the version it got removed.
    pub since: &'static str,
    issue: Option<NonZero<u32>>,
    }

  6. jyn514 commented on May 27, 2025

    @jyn514
    MemberAuthor

    hm. ideally we would not give wrong info in the diagnostic. are you willing to go through the git history for each feature one by one and see when it was removed? i think it will not be as bad as it sounds, a github blame view will get you 80% of the info you need because each commit links to the PR it's from (and the PR has a version number). it might also be possible to script this.

    if you are willing, please note down the PR number as you do this, that will save someone from having to do the work again.

  7. xizheyin commented on May 27, 2025

    @xizheyin
    Member

    No problem, I've just submitted #141642 to finish this for now, not sure if we want to merge this PR first before we go back to gradually fixing the diagnostic info.

  8. added 2 commits that reference this issue on Jun 10, 2025
    00a869b
    2aea4b2
  9. added a commit that references this issue on Jun 10, 2025
    f19ec2e
  10. added a commit that references this issue on Jun 14, 2025
    6323f8d
  11. compiler-errors commented on Jun 24, 2025

    @compiler-errors
    Contributor

    Noting here that we decided to roll back #141642 in #142943, since it has some test normalization concerns and it doesn't seem to be critical to implement this just yet. Any further attempts to fix this should pay close attention to making sure this doesn't break beta promotion or cause any test normalization headaches.

  12. xizheyin commented on Jun 24, 2025

    @xizheyin
    Member

    It seems that only current_version has been deleted in #142943. When I added the test, I also felt that the regular expression of the version number was strange.

    But IMO, #142943 has no substantial influence on this issue.

  13. compiler-errors commented on Jun 24, 2025

    @compiler-errors
    Contributor

    Right; I guess I'll clarify that we're rolling back part of that change (the current version part). We still keep the version where a feature was removed. I think that's the more important part of this feature request, and the part that's much easier to maintain.

    I'll close this unless jyn particularly wants us to note the current version when noting that a feature is removed, which probably should be re-opened as a new issue so that discussion can properly weigh the pros and cons of maintaining such a feature.

  14. xizheyin commented on Jun 24, 2025

    @xizheyin
    Member

    Ok, don't worry, because we can easily get the current version information through rustc -vV. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-help-wantedCall for participation: Help is requested to fix this issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions