-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Don't include current rustc version string in feature removed help #142943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
4a24662
to
979fd4e
Compare
The version string is difficult to properly normalize out, and removing it isn't a huge deal (the user can query version info easily through `rustc --version` or `cargo --version`). The normalization options were all non-ideal: - Per-test version string normalization is nasty to maintain, and we need to maintain `n` copies of it. - Centralized compiletest normalization (with a directive opt-out) is also not ideal, because `cfg(version(..))` tests can't have those accidentally normalized out (and you'd have to remember to opt-out).
979fd4e
to
db11e74
Compare
Does this need beta nomination? |
Rollup of 9 pull requests Successful merges: - #142645 (Also emit suggestions for usages in the `non_upper_case_globals` lint) - #142657 (mbe: Clean up code with non-optional `NonterminalKind`) - #142799 (rustc_session: Add a structure for keeping both explicit and default sysroots) - #142805 (Emit a single error when importing a path with `_`) - #142882 (Lazy init diagnostics-only local_names in borrowck) - #142883 (Add impl_trait_in_bindings tests from #61773) - #142943 (Don't include current rustc version string in feature removed help) - #142965 ([RTE-497] Ignore `c-link-to-rust-va-list-fn` test on SGX platform) - #142972 (Add a missing mailmap entry) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #142943 - jieyouxu:no-rustc-version, r=compiler-errors Don't include current rustc version string in feature removed help The version string is difficult to properly normalize out, and removing it isn't a huge deal (the user can query version info easily through `rustc --version` or `cargo --version`). The normalization options were all non-ideal (see #142940 (comment)): - Per-test version string normalization is nasty to maintain, and we need to maintain `n` copies of it. See #142930 where the regex wasn't robust against different release channels. - Centralized compiletest normalization (with a directive opt-out) is also not ideal, because `cfg(version(..))` tests can't have those accidentally normalized out (and you'd have to remember to opt-out). r? `@workingjubilee` (discussed in #142940)
TL;DR: no. Sorry, I should've included more context:
I'll edit the PR description to include this further elaboration. |
Yep, that's the part I was too lazy to look up.
Yeah, I corrected myself about that here: #141619 (comment) |
This PR removes the current rust version substring in the help message introduced in #141642, not the whole help or the removal version (i.e. the "spirit" of #141619 is still preserved). Only the "current rust version" substring normalization is the hard-to-normalize bit.
The current version string is difficult to properly normalize out, and removing it isn't a huge deal (the user can query version info easily through
rustc --version
orcargo --version
).The normalization options were all non-ideal (see #142940 (comment)):
n
copies of it. See Account for beta revisions when normalizing versions #142930 where the regex wasn't robust against different release channels.cfg(version(..))
tests can't have those accidentally normalized out (and you'd have to remember to opt-out).More context
.beta
substring on the beta channel. That PR is already beta-backported, so this PR does not need to be.