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 24 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`.
…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-testsuite Area: The testsuite used to check the correctness of rustc 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 30fdfca 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
@GuillaumeGomez
Copy link
Member Author

Gonna close it to include another PR in a bigger rollup. =D

@GuillaumeGomez GuillaumeGomez deleted the rollup-4q7vds6 branch July 20, 2025 13:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc 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.

9 participants