Skip to content

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented Jul 20, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

nxsaken and others added 27 commits July 1, 2025 17:02
When a snapshot test fails, it only emits a `.pending-snap` file for the first
snapshot assertion that actually failed, because subsequent assertions aren't
executed. That makes it cumbersome to re-bless tests that contain multiple
snapshot assertions.
codegen tests typically depend on the raw LLVM IR output and are
sensitive to debuginfo level. So do not apply
`rust.debuginfo-level-tests` for codegen tests.

Before this commit:

    $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
    test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s

After this commit:

    $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
    NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
    test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s
The current behaviour introduced by commit
a50a3b8 would discard any
target features specified after crt-static (the only member of
RUSTC_SPECIFIC_FEATURES). This is because it returned instead of
continuing processing the next flag.

Signed-off-by: Jens Reidel <[email protected]>
The test relies on LLVM not merging all the globals into one and would
currently otherwise fail on powerpc64le.

Signed-off-by: Jens Reidel <[email protected]>
The conversation in 143502 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all.

This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true.  I'll try out such a world next :)
Looks like the output it's looking for can be in different orders, so separate tests will fix that.
Add `uX::strict_sub_signed`

rust-lang#116090 missed `strict_sub_signed`, adding it here.
Part of rust-lang#118260.

r? ``@m-ou-se``
address clippy formatting nits

- int_log10.rs: change top level doc comments to outer
- collect.rs: remove empty line after doc comment
- clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented
- clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
…lcnr

Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too

The conversation in rust-lang#143502 (comment) made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all.

This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true.  (See rust-lang#143860 for more.)
…=Kobzol

bootstrap: Don't trigger an unnecessary LLVM build from check builds

Coming back to r-l/r development after a few weeks away, I found a major regression in my dev workflows: running `x check compiler` (either manually or via rust-analyzer) would have the side-effect of building LLVM, even though that shouldn't be necessary.

For my main build directory this would be a minor annoyance, but for my separate rust-analyzer build directory it's a huge problem because it causes a completely separate build of LLVM, which takes a long time and should be completely unnecessary.

---

After some investigation, I tracked down the problem to the `can_skip_build` check in this code:

https://github.com/rust-lang/rust/blob/3014e79f9c8d5510ea7b3a3b70d171d0948b1e96/src/bootstrap/src/core/build_steps/compile.rs#L1382-L1396

Historically, this would skip the LLVM build for stage 0 check builds. But after the recent stage 0 std redesign and some associated check stage renumbering (e.g. rust-lang#143048), the condition `builder.top_stage == build_stage` is now false, because `top_stage` is 1 (due to the renumbering) but `build_stage` is 0 (because a “stage 1” non-library check build still uses the stage 0 compiler).

---

Because this is a critical contributor roadblock for me, I have tried to fix this in a relatively narrow way. It's possible that all of this surrounding logic could be greatly simplified (especially in light of the stage redesign changes), but I didn't want this fix to be held back by scope creep.

---

(Zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20incorrectly.20building.20LLVM.20for.20check.20builds/near/528991035)
…=Mark-Simulacrum

bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests

As dicussed in rust-lang#61117 (comment), codegen tests typically depend on the raw LLVM IR output and are sensitive to debuginfo level. So do not apply `rust.debuginfo-level-tests` for codegen tests.

Before this commit:

    $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
    test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s

After this commit:

    $ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
    NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
    test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s

### Run this in CI?

Maybe it will make sense to add this to CI later but I think it is too early to do now before more non-codegen tests work with `rust.debuginfo-level-tests=2`.
…Kobzol

Add new `ignore-backends` and `needs-backends` tests annotations

Part of rust-lang/compiler-team#891.

Next step will be to add these annotations in the files where either the output is different based on the codegen (like `asm` tests) or that are known to fail in the GCC backend.

cc `@oli-obk` `@antoyo`
r? `@Kobzol`
…ic, r=RalfJung

Fix `-Ctarget-feature`s getting ignored after `crt-static`

The current behaviour introduced by commit a50a3b8 would discard any target features specified after `crt-static` (the only member of `RUSTC_SPECIFIC_FEATURES`). This is because it returned instead of continuing processing the next feature.

I wasn't entirely sure how the regression test should look like, but this one should do. If anyone has some suggestions, I'm happy to learn, it's my first test :)

I've confirmed that the test fails without the fix on `powerpc64le-unknown-linux-musl` and `x86_64-unknown-linux-gnu`.

cc ``@RalfJung``
…lacrum

tests: assembly: cstring-merging: Disable GlobalMerge pass

The test relies on LLVM not merging all the globals into one and would currently otherwise fail on powerpc64le.

See https://github.com/llvm/llvm-project/blob/release/20.x/llvm/lib/CodeGen/GlobalMerge.cpp and here's the assembly generated prior to disabling the pass:

<details>

<summary>Expand me</summary>

```asm
	.abiversion 2
	.file	"cstring_merging.5aa81ea7b99b31fe-cgu.0"
	.section	.text.cstr,"ax",``@progbits``
	.globl	cstr
	.p2align	4
	.type	cstr,``@function``
cstr:
.Lfunc_begin0:
	.cfi_startproc
.Lfunc_gep0:
	addis 2, 12, .TOC.-.Lfunc_gep0@ha
	addi 2, 2, .TOC.-.Lfunc_gep0@l
.Lfunc_lep0:
	.localentry	cstr, .Lfunc_lep0-.Lfunc_gep0
	addis 3, 2, .L_MergedGlobals@toc@ha
	li 4, 4
	addi 3, 3, .L_MergedGlobals@toc@l
	addi 3, 3, 4
	blr
	.long	0
	.quad	0
.Lfunc_end0:
	.size	cstr, .Lfunc_end0-.Lfunc_begin0
	.cfi_endproc

	.section	.text.manual_cstr,"ax",``@progbits``
	.globl	manual_cstr
	.p2align	4
	.type	manual_cstr,``@function``
manual_cstr:
.Lfunc_begin1:
	.cfi_startproc
.Lfunc_gep1:
	addis 2, 12, .TOC.-.Lfunc_gep1@ha
	addi 2, 2, .TOC.-.Lfunc_gep1@l
.Lfunc_lep1:
	.localentry	manual_cstr, .Lfunc_lep1-.Lfunc_gep1
	addis 3, 2, .L_MergedGlobals@toc@ha
	li 4, 4
	addi 3, 3, .L_MergedGlobals@toc@l
	addi 3, 3, 8
	blr
	.long	0
	.quad	0
.Lfunc_end1:
	.size	manual_cstr, .Lfunc_end1-.Lfunc_begin1
	.cfi_endproc

	.type	CSTR,``@object``
	.section	.data.rel.ro.CSTR,"aw",``@progbits``
	.globl	CSTR
	.p2align	3, 0x0
CSTR:
	.quad	.L_MergedGlobals
	.size	CSTR, 8

	.type	.L_MergedGlobals,``@object``
	.section	.rodata..L_MergedGlobals,"a",``@progbits``
.L_MergedGlobals:
	.asciz	"foo"
	.asciz	"bar"
	.asciz	"baz"
	.size	.L_MergedGlobals, 12

.set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, .L_MergedGlobals
	.size	.Lanon.a643e9a6bba67b7953be2b5f96e0e802.0, 4
.set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, .L_MergedGlobals+4
	.size	.Lanon.a643e9a6bba67b7953be2b5f96e0e802.1, 4
.set .Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, .L_MergedGlobals+8
	.size	.Lanon.a643e9a6bba67b7953be2b5f96e0e802.2, 4
	.ident	"rustc version 1.90.0-dev"
	.section	".note.GNU-stack","",``@progbits``
```

</details>
…idation, r=RalfJung

Give a message with a span on MIR validation error

It was handy to get a source+line link for rust-lang#143833, even if it's just to the function and not necessarily to the statement.

r? mir
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc labels Jul 20, 2025
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jul 20, 2025
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=5 rollup=never

@bors
Copy link
Collaborator

bors commented Jul 20, 2025

📌 Commit ae3708e has been approved by GuillaumeGomez

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 Jul 20, 2025
@bors
Copy link
Collaborator

bors commented Jul 20, 2025

⌛ Testing commit ae3708e with merge 0864097...

@bors
Copy link
Collaborator

bors commented Jul 20, 2025

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing 0864097 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 20, 2025
@bors bors merged commit 0864097 into rust-lang:master Jul 20, 2025
12 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 20, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#143282 Add uX::strict_sub_signed 8de864e25aed63dd471037ac29e3c84a7d9248d5 (link)
#143423 address clippy formatting nits 61f2a22a6d3116e15c4df02c201d186799cfc298 (link)
#143720 Allow Rvalue::Repeat to return true in `rvalue_creates_op… 352ca20ee9c22e062355507da7bf54427ecf13f4 (link)
#144011 bootstrap: Don't trigger an unnecessary LLVM build from che… 540d550bb6dc788082a652abf79740886362bc49 (link)
#144112 bootstrap: Ignore rust.debuginfo-level-tests for codegen … fc2242b3be632bd54d8385bd39ec66605a19ce4d (link)
#144125 Add new ignore-backends and needs-backends tests annota… b2459e8c5a4ace9d74779d51a556f1c4e6e79c38 (link)
#144143 Fix -Ctarget-features getting ignored after crt-static 08bc390b2372db3ab8e25bfd52afd5c97ca7185a (link)
#144150 tests: assembly: cstring-merging: Disable GlobalMerge pass 75f0da039e84391e78b3ec595c91cd7bafd6277e (link)
#144190 Give a message with a span on MIR validation error 817bc677e8ddabf7a3b8d7e0ad6a957c0d05e774 (link)

previous master: ca9eecda36

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

Copy link
Contributor

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 ca9eecd (parent) -> 0864097 (this PR)

Test differences

Show 1574 test diffs

Stage 0

  • core::builder::tests::snapshot::build_rustc_no_explicit_stage: [missing] -> pass (J1)
  • core::builder::tests::snapshot::check_rustc_no_explicit_stage: [missing] -> pass (J1)

Stage 1

  • [codegen] tests/codegen/repeat-operand-zero-len.rs: [missing] -> pass (J0)
  • [codegen] tests/codegen/repeat-operand-zst-elem.rs: [missing] -> pass (J0)
  • [ui] tests/ui/cfg/crt-static-with-target-features-works.rs: [missing] -> pass (J0)

Stage 2

  • [codegen] tests/codegen/repeat-operand-zero-len.rs: [missing] -> pass (J2)
  • [codegen] tests/codegen/repeat-operand-zst-elem.rs: [missing] -> pass (J2)
  • [ui] tests/ui/cfg/crt-static-with-target-features-works.rs: [missing] -> pass (J3)

Additionally, 1566 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 0864097cd31ee30f5081ba588a5c9820c2c6fc71 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-apple-various: 5384.0s -> 8254.4s (53.3%)
  2. x86_64-apple-2: 4555.8s -> 5620.3s (23.4%)
  3. x86_64-apple-1: 8299.5s -> 9483.8s (14.3%)
  4. aarch64-apple: 4030.3s -> 4555.6s (13.0%)
  5. dist-x86_64-apple: 10050.3s -> 8960.3s (-10.8%)
  6. dist-aarch64-apple: 5216.8s -> 5698.6s (9.2%)
  7. dist-x86_64-msvc: 6106.9s -> 6523.3s (6.8%)
  8. dist-arm-linux-musl: 5293.3s -> 5588.8s (5.6%)
  9. x86_64-gnu-tools: 3522.0s -> 3333.5s (-5.4%)
  10. pr-check-1: 1550.2s -> 1473.3s (-5.0%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0864097): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.4%, secondary -4.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.4% [-2.4%, -2.4%] 2
Improvements ✅
(secondary)
-4.0% [-4.0%, -4.0%] 1
All ❌✅ (primary) -2.4% [-2.4%, -2.4%] 2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 465.087s -> 466.613s (0.33%)
Artifact size: 374.54 MiB -> 374.57 MiB (0.01%)

@GuillaumeGomez GuillaumeGomez deleted the rollup-ha29sql branch July 20, 2025 19:21
Muscraft pushed a commit to Muscraft/rust that referenced this pull request Jul 21, 2025
…llaumeGomez

Rollup of 9 pull requests

Successful merges:

 - rust-lang#143282 (Add `uX::strict_sub_signed`)
 - rust-lang#143423 (address clippy formatting nits)
 - rust-lang#143720 (Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too)
 - rust-lang#144011 (bootstrap: Don't trigger an unnecessary LLVM build from check builds)
 - rust-lang#144112 (bootstrap: Ignore `rust.debuginfo-level-tests` for codegen tests)
 - rust-lang#144125 (Add new `ignore-backends` and `needs-backends` tests annotations)
 - rust-lang#144143 (Fix `-Ctarget-feature`s getting ignored after `crt-static`)
 - rust-lang#144150 (tests: assembly: cstring-merging: Disable GlobalMerge pass)
 - rust-lang#144190 (Give a message with a span on MIR validation error)

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants