Skip to content

Rollup of 8 pull requests #144217

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

Closed
wants to merge 24 commits into from

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