Repository navigation
Closed
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call 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.Call for participation: Help is requested to fix this issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
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 defaultDesired 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 invocationsRationale 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
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call 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.Call for participation: Help is requested to fix this issue.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
jyn514 commentedon May 27, 2025
oh neat, we already track version:
rust/compiler/rustc_feature/src/removed.rs
Line 43 in 30721b0
that makes the version part of this quite simple, and we can add pr info later.
mentoring instructions: in
rust/compiler/rustc_expand/src/config.rs
Lines 82 to 89 in 30721b0
noteabout when the feature was removed.@rustbot label E-help-wanted E-easy
xizheyin commentedon May 27, 2025
@rustbot claim
xizheyin commentedon May 27, 2025
For removed feature, the version may be not accurate, is this some kind of historical problem?
rust/compiler/rustc_feature/src/lib.rs
Lines 33 to 41 in 30721b0
jyn514 commentedon May 27, 2025
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.
xizheyin commentedon May 27, 2025
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.
Rollup merge of rust-lang#141642 - xizheyin:issue-141619, r=BoxyUwU
Rollup merge of rust-lang#141642 - xizheyin:issue-141619, r=BoxyUwU
Unrolled build for #141642
Rollup merge of #141642 - xizheyin:issue-141619, r=BoxyUwU
compiler-errors commentedon Jun 24, 2025
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.
xizheyin commentedon Jun 24, 2025
It seems that only
current_versionhas 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.
compiler-errors commentedon Jun 24, 2025
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.
xizheyin commentedon Jun 24, 2025
Ok, don't worry, because we can easily get the current version information through
rustc -vV. :)