Skip to content

Rollup of 13 pull requests - #153116

Merged
rust-bors[bot] merged 32 commits into
rust-lang:mainfrom
jhpratt:rollup-yjBVB1Y
Feb 26, 2026
Merged

Rollup of 13 pull requests#153116
rust-bors[bot] merged 32 commits into
rust-lang:mainfrom
jhpratt:rollup-yjBVB1Y

Conversation

@jhpratt

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost

Create a similar rollup

the8472and others added 30 commits December 26, 2025 17:02
cleaning up disk space takes a lot of time
Co-authored-by: Marco Ieni <11428655+marcoieni@users.noreply.github.com>
we assume the disks are ext4, but GH doesn't guarantee that.
…t_abi for ABI determination
Currently on PowerPC64 targets, llvm_abiname and target_abi will be the
same unless we're on AIX. Since llvm_abiname is what we pass on to LLVM,
it is preferable to use the value of that to determine the calling
convention rather than target_abi.
All PowerPC64 targets set both llvm_abiname and target_abi to the
respective ELF ABIs, with the exception of AIX. This is a non-functional
change.
Previously this was not correctly implemented. Each funclet may need its own terminate
block, so this changes the `terminate_block` into a `terminate_blocks` `IndexVec` which
can have a terminate_block for each funclet. We key on the first basic block of the
funclet -- in particular, this is the start block for the old case of the top level
terminate function.
Rather than using a catchswitch/catchpad pair, I used a cleanuppad. The reason for the
pair is to avoid catching foreign exceptions on MSVC. On wasm, it seems that the
catchswitch/catchpad pair is optimized back into a single cleanuppad and a catch_all
instruction is emitted which will catch foreign exceptions. Because the new logic is
only used on wasm, it seemed better to take the simpler approach seeing as they do the
same thing.
All callers of `is_ty_must_use()`, recursive or not, pass `span` as equal
to `expr.span` alongside `expr`. The `span` parameter can be safely removed.
The name `pass_by_value` is completely wrong. The lint actually checks
for the use of pass by reference for types marked with
`rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_`
part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy
lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
It has a single use and doesn't provide any real value. Removing it
allows the removal of two `for<'tcx>` qualifiers.
`QuerySystem` has two function pointers: `encode_query_results` and
`try_mark_green`. These exist so that `rustc_middle` can call functions
from upstream crates.
But we have a more general mechanism for that: hooks. So this commit
converts these two cases into hooks.
Fix: On wasm targets, call `panic_in_cleanup` if panic occurs in cleanup
Previously this was not correctly implemented. Each funclet may need its own terminate block, so this changes the `terminate_block` into a `terminate_blocks` `IndexVec` which can have a terminate_block for each funclet. We key on the first basic block of the funclet -- in particular, this is the start block for the old case of the top level terminate function.
I also fixed the `terminate` handler to not be invoked when a foreign exception is raised, mimicking the behavior from msvc. On wasm, in order to avoid generating a `catch_all` we need to call `llvm.wasm.get.exception` and `llvm.wasm.get.ehselector`.
…ame, r=RalfJung
rustc_target: callconv: powerpc64: Use llvm_abiname rather than target_abi for ABI determination
Currently on PowerPC64 targets, `llvm_abiname` and `target_abi` will be the same unless we're on AIX. Since `llvm_abiname` is what we pass on to LLVM, it is preferable to use the value of that to determine the calling convention rather than `target_abi`.
All PowerPC64 targets set both `llvm_abiname` and `target_abi` to the respective ELF ABIs, with the exception of AIX. This is a non-functional change.
Noticed this in the follow-up discussion from rust-lang#150468 and also requested by @RalfJung [here](rust-lang#150468 (comment)).
r? @RalfJung
mGCA: Lower negated literals directly and reject non-integer negations
follow up rust-lang#152001resolve: rust-lang#152246
r? BoxyUwU
…etrochenkov
Remove `QuerySystemFns`
Two small query-related cleanups.
r? petrochenkov
interpret: avoid dummy spans in the stacktrace
This should fixrust-lang/miri#4871
…rn-is-absolute, r=notriddle
Refactor url_parts to return is_absolute instead of out param
Follow-up from rust-lang#152977.
Changes `url_parts` to return `Result<(UrlPartsBuilder, bool), HrefError>` instead of taking `is_absolute: &mut bool` as an out parameter. Also clarifies variable name in `generate_item_def_id_path` where the final URL string was called `url_parts`.
No behavior change, pure refactor.
r? @notriddle
…od, r=madsmtm
deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls
The `Eq::assert_receiver_is_total_eq` method is purely meant as an implementation detail by `#[derive(Eq)]` to add checks that all fields of the type the derive is applied to also implement `Eq`.
The method is already `#[doc(hidden)]` and has a comment saying `// This should never be implemented by hand.`.
Unfortunately, it has been stable since 1.0 and there are some cases on GitHub (https://github.com/search?q=assert_receiver_is_total_eq&type=code) where people have implemented this method manually, sometimes even with actual code in the method body (example: https://github.com/Shresht7/codecrafters-redis-rust/blob/31f0ec453c504b4ab053a7b1c3ff548ff36a9db5/src/parser/resp/types.rs#L255).
To prevent further confusion from this, this PR is deprecating the method and adds a FCW when it is manually implemented (this is necessary as the deprecation warning is not emitted when the method is implemented, only when it is called).
This is similar to what was previously done with the `soft_unstable` lint (rust-lang#64266).
See also rust-lang/libs-team#704.
…, r=Urgau
Rename `rustc::pass_by_value` lint as `rustc::disallowed_pass_by_ref`.
The name `pass_by_value` is completely wrong. The lint actually checks for the use of pass by reference for types marked with `rustc_pass_by_value`.
The hardest part of this was choosing the new name. The `disallowed_` part of the name closely matches the following clippy lints:
- `disallowed_macros`
- `disallowed_methods`
- `disallowed_names`
- `disallowed_script_idents`
- `disallowed_types`
The `pass_by_value` part of the name aligns with the following clippy lints:
- `needless_pass_by_value`
- `needless_pass_by_ref_mut`
- `trivially_copy_pass_by_ref`
- `large_types_passed_by_value` (less so)
r? @Urgau
…-parameter, r=petrochenkov
`is_ty_must_use`: do not require a `span` argument
All callers of `is_ty_must_use()`, recursive or not, pass `span` as equal to `expr.span` alongside `expr`. The `span` parameter can be safely removed.
Update books
## rust-lang/reference
4 commits in 442cbef9105662887d5eae2882ca551f3726bf28..50a1075e879be75aeec436252c84eef0fad489f4
2026-02-25 00:55:28 UTC to 2026-02-24 17:09:35 UTC
- Fix formatting of markdown grammar with cut (rust-lang/reference#2183)
- Add support for named repeat ranges (rust-lang/reference#2181)
- paths: align singular/plural in `paths.canonical.intro` (rust-lang/reference#2142)
- `cfg_select!` macro (rust-lang/reference#2103)
@rustbotrustbot added the T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. label Feb 26, 2026
@jhpratt

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=5

@rust-bors

rust-borsBot commented Feb 26, 2026

Copy link
Copy Markdown
Contributor

📌 Commit efae53b has been approved by jhpratt

It is now in the queue for this repository.

@rust-borsrust-borsBot 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 Feb 26, 2026
@rust-bors

This comment has been minimized.

@rust-borsrust-borsBot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 26, 2026
@rust-bors

rust-borsBot commented Feb 26, 2026

Copy link
Copy Markdown
Contributor

☀️ Test successful - CI
Approved by: jhpratt
Duration: 3h 21m 5s
Pushing f02672c to main...

@rust-bors
rust-borsBot merged commit f02672c into rust-lang:mainFeb 26, 2026
12 checks passed
@rustbotrustbot added this to the 1.95.0 milestone Feb 26, 2026
This was referenced Feb 26, 2026
@github-actions

Copy link
Copy Markdown
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 1ed4882 (parent) -> f02672c (this PR)

Test differences

Show 357 test diffs

Stage 1

  • [codegen] tests/codegen-llvm/double_panic_wasm.rs: [missing] -> ignore (ignored on targets without unwinding support) (J1)
  • [codegen] tests/codegen-llvm/double_panic_wasm.rs: [missing] -> ignore (only executed when the architecture is wasm32) (J2)
  • [ui] tests/ui-fulldeps/internal-lints/rustc_pass_by_value.rs: ignore (up-to-date) -> ignore (ignored when the bootstrapping stage is stage1 ((this can be removed when nightly goes to 1.96))) (J2)
  • [ui] tests/ui/deriving/internal_eq_trait_method_impls.rs: [missing] -> pass (J2)

Stage 2

  • [ui] tests/ui/deriving/internal_eq_trait_method_impls.rs: [missing] -> pass (J0)
  • [codegen] tests/codegen-llvm/double_panic_wasm.rs: [missing] -> ignore (only executed when the architecture is wasm32) (J3)
  • [run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression or LLVM is not the default codegen backend) -> pass (J4)

Additionally, 350 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 f02672cb8bffef88934d31d9044257a4d11e5d1f --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-aarch64-linux: 2h 28m -> 1h 51m (-25.2%)
  2. pr-check-2: 54m 44s -> 42m 58s (-21.5%)
  3. dist-apple-various: 2h 8m -> 1h 43m (-19.7%)
  4. x86_64-gnu-nopt: 2h 58m -> 2h 25m (-18.2%)
  5. x86_64-rust-for-linux: 1h 3m -> 51m 42s (-18.1%)
  6. pr-check-1: 41m 29s -> 34m 29s (-16.9%)
  7. aarch64-apple: 3h 50m -> 3h 13m (-15.9%)
  8. aarch64-gnu-llvm-20-1: 53m 28s -> 1h 1m (+15.5%)
  9. i686-gnu-2: 1h 30m -> 1h 42m (+14.0%)
  10. arm-android: 1h 59m -> 1h 44m (-12.6%)
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
Copy Markdown
Collaborator

📌 Perf builds for each rolled up PR:

PR#MessagePerf Build Sha
#148146CI: use alternative disks if available74c974e80bb1591613822c77adde78e4e6b4f4ea (link)
#149978deprecate Eq::assert_receiver_is_total_eq and emit FCW on…74d03a92c6be7c97317cee466136ba41677065bd (link)
#151771Fix: On wasm targets, call panic_in_cleanup if panic occu…878603b4734bc24bd4b95742c1d5918ec215bdd8 (link)
#153029Rename rustc::pass_by_value lint as `rustc::disallowed_pa…141e61d810b48adba1a90ff091a25930cbf3ffc3 (link)
#153035rustc_target: callconv: powerpc64: Use llvm_abiname rather …a52ed2969a47727329954843e8c38e4dc2d3486c (link)
#153063is_ty_must_use: do not require a span argument0528fd4241ded9d46cb100abe9d3078e7162cb8c (link)
#153071Update books406fa550663397fb5469f73edd6dddee5a4f94f5 (link)
#153075mGCA: Lower negated literals directly and reject non-intege…eb9365bc4a9ce122012351a3eb92cce453b0de36 (link)
#153078Remove QuerySystemFns761cc7e83cf08d2331cf4ab69afddd9767e23a33 (link)
#153089interpret: avoid dummy spans in the stacktrace0fb636bb1bfe2bdfab3e34e8bef47790f6a6fe9d (link)
#153092Remove redundant self usagesfd3c400162bcad4b5d96b6216892f8444ad33543 (link)
#153094Simplify AppendOnlyVec iteratorse64736d437b25d9197c3463524fffdbb6f1732c6 (link)
#153111Refactor url_parts to return is_absolute instead of out par…92baae4aceddf17ca48a77450e719db9d601b44b (link)

previous master: 1ed488274b

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

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (f02672c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

meanrangecount
Regressions ❌
(primary)
0.5%[0.3%, 1.0%]4
Regressions ❌
(secondary)
2.6%[0.3%, 5.9%]5
Improvements ✅
(primary)
-0.5%[-0.5%, -0.5%]1
Improvements ✅
(secondary)
-0.3%[-0.3%, -0.3%]1
All ❌✅ (primary)0.3%[-0.5%, 1.0%]5

Max RSS (memory usage)

Results (primary 2.5%, secondary 2.7%)

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

meanrangecount
Regressions ❌
(primary)
4.2%[1.4%, 7.4%]5
Regressions ❌
(secondary)
2.7%[0.9%, 4.9%]6
Improvements ✅
(primary)
-5.6%[-5.6%, -5.6%]1
Improvements ✅
(secondary)
--0
All ❌✅ (primary)2.5%[-5.6%, 7.4%]6

Cycles

Results (primary 2.7%, secondary 3.0%)

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

meanrangecount
Regressions ❌
(primary)
2.7%[2.7%, 2.7%]1
Regressions ❌
(secondary)
3.0%[3.0%, 3.1%]2
Improvements ✅
(primary)
--0
Improvements ✅
(secondary)
--0
All ❌✅ (primary)2.7%[2.7%, 2.7%]1

Binary size

Results (primary 0.3%, secondary 3.0%)

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

meanrangecount
Regressions ❌
(primary)
0.3%[0.0%, 1.3%]34
Regressions ❌
(secondary)
3.0%[0.1%, 12.8%]15
Improvements ✅
(primary)
-0.5%[-0.5%, -0.5%]1
Improvements ✅
(secondary)
--0
All ❌✅ (primary)0.3%[-0.5%, 1.3%]35

Bootstrap: 492.161s -> 479.407s (-2.59%)
Artifact size: 395.78 MiB -> 395.80 MiB (0.00%)

@rustbotrustbot added the perf-regression Performance regression. label Feb 26, 2026
@JonathanBrouwer

Copy link
Copy Markdown
Member

Started perf runs on #153075#153078#153089

@jhpratt
jhpratt deleted the rollup-yjBVB1Y branch February 26, 2026 20:02
@JonathanBrouwer

JonathanBrouwer commented Feb 26, 2026

Copy link
Copy Markdown
Member

None of them were the cause, started 3 more: #149978#151771#153035

@JonathanBrouwer

Copy link
Copy Markdown
Member

Regression is caused by #149978
@rustbot label: +perf-regression-triaged

@rustbotrustbot added the perf-regression-triaged The performance regression has been triaged. label Feb 27, 2026
@lqd

lqd commented Feb 27, 2026

Copy link
Copy Markdown
Member

For triage purposes: the regression will be addressed by #153157

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributesArea: Attributes (`#[…]`, `#![…]`)A-CIArea: Our Github Actions CIA-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-query-systemArea: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html)A-testsuiteArea: The testsuite used to check the correctness of rustcmerged-by-borsThis PR was explicitly merged by bors.perf-regressionPerformance regression.perf-regression-triagedThe performance regression has been triaged.rollupA PR which is a rollupT-clippyRelevant to the Clippy team.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-infraRelevant to the infrastructure team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-rust-analyzerRelevant to the rust-analyzer team, which will review and decide on the PR/issue.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.T-rustdoc-frontendRelevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

16 participants

@jhpratt@rust-timer@JonathanBrouwer@lqd@rustbot@the8472@Gelbpunkt@hoodmane@samueltardieu@reddevilmidzy@nnethercote@cyrgani@RalfJung@mu001999@cuviper@arferreira