-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[WIP] Normalize rust version string centrally in compiletest #142940
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
Several UI tests have a `normalize-stderr` for "you are using x.y.z" rustc versions, and that regex is flexible enough for suffixes like "-nightly" and "-dev", but not for "-beta.N". We can just add '.' to that trailing pattern to include this.
I believe this normalization can technically fail if you try to run these ui tests against a stage 0 beta compiler (which has a different version string than stage 1+ compiler that uses the "current" version string). However I don't think ui test suite supports being run against stage 0 compiler, surely quite a few ui tests will fail due to compiler differences themselves. |
This comment has been minimized.
This comment has been minimized.
There is a test that tests |
002c00b
to
477627d
Compare
Hm, good point, let me double-check. |
You're right. We can't naively do the normalization like in this PR. Some options:
Honestly, I'm leaning towards option (3). |
option 3 seems like the thing to do, yes. |
I'm going to close this PR, and instead go with option (3) in another PR. IMO it's not a huge loss, because you can just |
…ler-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 rust-lang#142940 (comment)): - Per-test version string normalization is nasty to maintain, and we need to maintain `n` copies of it. See rust-lang#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 rust-lang#142940)
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)
Caution
Stacked on top of #142930, that needs to merge first then this PR needs to be rebased.
Instead of maintaining
n
copies ofNormalize this consistently and centrally in compiletest instead.
cc @cuviper
r? @Kobzol