Skip to content

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

Merged
merged 1 commit into from
Jun 25, 2025

Conversation

jieyouxu
Copy link
Member

@jieyouxu jieyouxu commented Jun 24, 2025

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 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 Account for beta revisions when normalizing versions #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).

More context

@rustbot
Copy link
Collaborator

rustbot commented Jun 24, 2025

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 24, 2025
@jieyouxu jieyouxu changed the title [WIP] Don't include current rustc version string in feature removed help Don't include current rustc version string in feature removed help Jun 24, 2025
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).
@jieyouxu jieyouxu marked this pull request as ready for review June 24, 2025 15:33
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 24, 2025
@compiler-errors
Copy link
Member

cc #141642
cc #141619

r? compiler-errors @bors r+ rollup

@bors
Copy link
Collaborator

bors commented Jun 24, 2025

📌 Commit db11e74 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 24, 2025
@compiler-errors
Copy link
Member

Does this need beta nomination?

bors added a commit that referenced this pull request Jun 24, 2025
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
@bors bors merged commit 4488018 into rust-lang:master Jun 25, 2025
10 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jun 25, 2025
rust-timer added a commit that referenced this pull request Jun 25, 2025
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)
@jieyouxu jieyouxu deleted the no-rustc-version branch June 25, 2025 01:28
@jieyouxu
Copy link
Member Author

Does this need beta nomination?

TL;DR: no.


Sorry, I should've included more context:

I'll edit the PR description to include this further elaboration.

@compiler-errors
Copy link
Member

The test normalizations failing against beta channel was addressed already in #142930, which only changes the per-test normalizations to account for a .beta substring on the beta channel. That PR is already beta-backported, so this PR does not need to be.

Yep, that's the part I was too lazy to look up.

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.

Yeah, I corrected myself about that here: #141619 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants