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
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
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 <adrian@travitia.xyz>
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
The test relies on LLVM not merging all the globals into one and would currently otherwise fail on powerpc64le. Signed-off-by: Jens Reidel <adrian@travitia.xyz>
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.

9 participants