Account for beta revisions when normalizing versions #142930
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.
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
rustbot
added
S-waiting-on-review
|
Here's where it failed in the beta promotion: #142920 (comment) @rustbot label beta-nominated |
rustbot
added
the
beta-nominated
|
@bors r+ rollup p=1 |
bors
added
S-waiting-on-bors
| @@ -1,4 +1,4 @@ | |||
| //@ normalize-stderr: "you are using [0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?( \([^)]*\))?" -> "you are using $$RUSTC_VERSION" | |||
| //@ normalize-stderr: "you are using [0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.]+)?( \([^)]*\))?" -> "you are using $$RUSTC_VERSION" | |||
There was a problem hiding this comment.
@cuviper Our regex syntax treats this [.] as a literal match on the character '.' and not a wildcard, right?
There was a problem hiding this comment.
I sure hope so -- that's true of every regex engine I know!
But really, it must be, or else this would be gobbling the rest of the line and definitely fail UI expectations.
There was a problem hiding this comment.
Yeah, that's my expectation too. Just that the next capturing group is ( \([^)]*\))? which is what made me wonder about details of how the regex is getting interpreted.
There was a problem hiding this comment.
That part is gobbling the git info within literal parentheses, e.g. 1.89.0-beta.1 (88b80702e 2025-06-23), and it's optional because some builds (like -dev) may not have that.
Mark-Simulacrum
added
the
beta-accepted
[beta] Prepare Rust 1.89.0 - Update version placeholders - Update channel to beta - Account for beta revisions when normalizing versions #142930 r? cuviper
…=workingjubilee Account for beta revisions when normalizing versions 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.
Rollup of 8 pull requests Successful merges: - #140622 (compiletest: Improve diagnostics for line annotation mismatches) - #142641 (Generate symbols.o for proc-macros too) - #142695 (Port `#[rustc_skip_during_method_dispatch]` to the new attribute system) - #142742 ([win][aarch64] Fix linking statics on Arm64EC, take 2) - #142894 (phantom_variance_markers: fix identifier usage in macro) - #142928 (Fix hang in --print=file-names in bootstrap) - #142930 (Account for beta revisions when normalizing versions) - #142932 (rustdoc-json: Keep empty generic args if parenthesized) r? `@ghost` `@rustbot` modify labels: rollup
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 99b18d6 (parent) -> e4b9d01 (this PR) Test differencesNo test diffs found Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard e4b9d0141fdd210fcceebd2b67f7be113401c461 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (e4b9d01): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -4.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 3.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 689.194s -> 690.402s (0.18%) |
…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)
Several UI tests have a
normalize-stderrfor "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.