Skip to content

Conversation

@Zalathar
Copy link
Member

@Zalathar Zalathar commented Nov 16, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

yotamofek and others added 23 commits November 5, 2025 12:54
    Updating crates.io index
     Locking 17 packages to latest compatible versions
    Updating addr2line v0.25.0 -> v0.25.1
    Updating cfg-if v1.0.1 -> v1.0.4
    Updating dlmalloc v0.2.10 -> v0.2.11
    Updating gimli v0.32.0 -> v0.32.3
    Updating vex-sdk v0.27.0 -> v0.27.1 (available: v0.28.0)
      Adding windows-link v0.2.1
    Updating windows-sys v0.59.0 -> v0.60.2
    Updating windows-targets v0.52.6 -> v0.53.5
    Updating windows_aarch64_gnullvm v0.52.6 -> v0.53.1
    Updating windows_aarch64_msvc v0.52.6 -> v0.53.1
    Updating windows_i686_gnu v0.52.6 -> v0.53.1
    Updating windows_i686_gnullvm v0.52.6 -> v0.53.1
    Updating windows_i686_msvc v0.52.6 -> v0.53.1
    Updating windows_x86_64_gnu v0.52.6 -> v0.53.1
    Updating windows_x86_64_gnullvm v0.52.6 -> v0.53.1
    Updating windows_x86_64_msvc v0.52.6 -> v0.53.1
    Updating wit-bindgen v0.45.0 -> v0.45.1
This sentence was unnecessarily complex; try to simplify it.
The overflow-checks codegen test was failing on riscv64gc target
because the FileCheck pattern did not account for ABI extension
attributes. RISC-V LP64 ABI requires integer types smaller than
XLEN (64-bit) to be zero-extended or sign-extended to register width.

For u8 parameters, RISC-V generates:
  i8 noundef zeroext %a, i8 noundef zeroext %b

While x86_64 and aarch64 generate:
  i8 noundef %a, i8 noundef %b

The original CHECK pattern only matched the format without the
`zeroext` attribute, causing test failures on RISC-V.

This patch makes the zeroext attribute optional in the FileCheck
pattern using `{{( zeroext)?}}`, allowing the test to pass on
architectures that add ABI extension attributes (e.g., RISC-V).

Test results before fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 1 passed, 2 failed

Test results after fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 3 passed
This enables rustup distribution of the rust-std component for the
riscv64a23-unknown-linux-gnu target, allowing users to install it via
`rustup target add riscv64a23-unknown-linux-gnu`.
The check is already done in enclosing code
…imulacrum

`vec_recycle`: implementation

Tracking issue: rust-lang#148227

Going with the `TransmuteFrom` approach suggested in rust-lang/libs-team#674 (comment), but a bit simplified.

Currently does not work in some places where it should due to the limitations of the current implementation of the transmutability analysis: rust-lang#148227 (comment)
…_postings_from_string, r=GuillaumeGomez

Micro-optimize rustdoc search index parsing

This should pre-allocate the correct size for the `slot` vec. Not sure how much of a difference it'll make, but let's see.
…parts, r=Mark-Simulacrum

Stabilize vec_into_raw_parts

This stabilizes `Vec::into_raw_parts()` and `String::into_raw_parts()` per FCP in rust-lang#65816 (comment). While this _does not_ stabilize `Vec::into_parts()`, I fixed up the examples that said they were waiting for `vec_into_raw_parts`. As `Vec::from_parts()` and `Vec::into_parts()` are covered by the same feature `box_vec_non_null`, any doctest that uses `Vec::from_parts()` can also use `Vec::into_parts()` (and same for allocator-aware versions).

Closes rust-lang#65816

``@rustbot`` modify labels: +T-libs-api
…ocs, r=Mark-Simulacrum

tweak primitive reference docs

This is a docs-only change for primitive reference.

I noticed a typo ("safe to use at type `T`") and fixed it to read "safe to use *as* type `T`".

While reading over the whole page, I also noticed another sentence that was hard to read. I tried to improve it: feel free to comment on the wisdom of this change...
…ecks-test-fail, r=Mark-Simulacrum

Fix overflow-checks test for RISC-V target

The overflow-checks codegen test was failing on riscv64gc target because the FileCheck pattern did not account for ABI extension attributes. RISC-V LP64 ABI requires integer types smaller than XLEN (64-bit) to be zero-extended or sign-extended to register width.

For u8 parameters, RISC-V generates:
  i8 noundef zeroext %a, i8 noundef zeroext %b

While x86_64 and aarch64 generate:
  i8 noundef %a, i8 noundef %b

The original CHECK pattern only matched the format without the `zeroext` attribute, causing test failures on RISC-V.

This patch makes the zeroext attribute optional in the FileCheck pattern using `{{( zeroext)?}}`, allowing the test to pass on architectures that add ABI extension attributes (e.g., RISC-V).

Test results before fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 1 passed, 2 failed

Test results after fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 3 passed
…-tier2, r=Mark-Simulacrum

Add riscv64a23-unknown-linux-gnu to build-manifest TARGETS

This enables rustup distribution of the rust-std component for the riscv64a23-unknown-linux-gnu target
(Previous PR rust-lang#148435 missed this step.)
… r=bjorn3

re-enable wasm abi test

The `wasm32-unknown-unknown` ABI has been fixed for a while now rust-lang#115666, so this test can be re-enabled and the fixme removed.

r? ``@bjorn3``
runtest.rs: remove redundant check

The check is already done in enclosing code
…Kivooeo

Add another *ExprWithBlock* test for `try` blocks

Looking to address this open item from rust-lang#31436

> Add a test confirming that it's an `ExprWithBlock`, so works in a match arm without a comma

It turns out that rust-lang#120540 addressed that one, but it made me think of this other case that probably ought to have some kind of test as well.
… r=Kivooeo

chore: Update annotate-snippets to 0.12.9

This PR updates `annotate-snippets` to `0.12.9`, which includes a fix for rust-lang#148070.

fixes rust-lang#148070
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool 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. labels Nov 16, 2025
@rustbot rustbot added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. rollup A PR which is a rollup labels Nov 16, 2025
@Zalathar
Copy link
Member Author

Rollup of everything.

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Nov 16, 2025

📌 Commit e00af8b has been approved by Zalathar

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 Nov 16, 2025
@bors
Copy link
Collaborator

bors commented Nov 16, 2025

⌛ Testing commit e00af8b with merge 67c4cf3...

@bors
Copy link
Collaborator

bors commented Nov 16, 2025

☀️ Test successful - checks-actions
Approved by: Zalathar
Pushing 67c4cf3 to main...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 16, 2025
@bors bors merged commit 67c4cf3 into rust-lang:main Nov 16, 2025
12 checks passed
@rustbot rustbot added this to the 1.93.0 milestone Nov 16, 2025
@github-actions
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 54f4176 (parent) -> 67c4cf3 (this PR)

Test differences

Show 803 test diffs

Stage 1

  • [ui] tests/ui/abi/compatibility.rs#wasm: [missing] -> pass (J0)
  • [ui] tests/ui/try-block/try-block-as-statement.rs: [missing] -> pass (J0)

Stage 2

  • [ui] tests/ui/abi/compatibility.rs#wasm: [missing] -> ignore (gcc backend is marked as ignore) (J1)
  • [ui] tests/ui/abi/compatibility.rs#wasm: [missing] -> pass (J2)
  • [ui] tests/ui/try-block/try-block-as-statement.rs: [missing] -> pass (J3)

Additionally, 798 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 67c4cf395f243afcb973dacdd39b16895c9ad295 --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. arm-android: 5359.7s -> 6204.5s (+15.8%)
  2. dist-various-1: 4372.2s -> 3793.0s (-13.2%)
  3. x86_64-gnu-tools: 3364.4s -> 3772.2s (+12.1%)
  4. x86_64-gnu-gcc: 3056.7s -> 3422.9s (+12.0%)
  5. x86_64-rust-for-linux: 2596.8s -> 2894.4s (+11.5%)
  6. i686-gnu-2: 5479.3s -> 6101.1s (+11.3%)
  7. x86_64-gnu-llvm-20-1: 3200.8s -> 3560.2s (+11.2%)
  8. x86_64-gnu-llvm-20: 2438.1s -> 2709.7s (+11.1%)
  9. dist-aarch64-apple: 6467.5s -> 5763.5s (-10.9%)
  10. i686-gnu-nopt-1: 7333.2s -> 8127.5s (+10.8%)
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

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#148416 vec_recycle: implementation ecf493efaa0e60b56a6f73407c1bb42142a2b98d (link)
#148522 Micro-optimize rustdoc search index parsing 0c6a8d4e329f4a186748970e1198086570cee89c (link)
#148827 Stabilize vec_into_raw_parts 5f6fc9de299e43a82a864a772246e57e7f2db80f (link)
#148832 Bump library dependencies ae7e6ce7435ae541bfc77c66f6799593f1e47618 (link)
#148836 tweak primitive reference docs e8306d61235f718e463e1619fbf07f945b507408 (link)
#148859 Fix overflow-checks test for RISC-V target 1b5e3e014562c6f114c41759187103eceddb76b6 (link)
#148886 Add riscv64a23-unknown-linux-gnu to build-manifest TARGETS 6103d8b94045f21d01dadb44aa79d82dc5ce0a0d (link)
#148956 re-enable wasm abi test d2bde6c8d032ca4d3ce0efa4698634454adb7ea6 (link)
#148963 runtest.rs: remove redundant check 378a1f94fad387376c95069e81b6b0f76bd5f4cf (link)
#148968 Add another ExprWithBlock test for try blocks 4f5da5129ea724a48729ee3383f56cb751b7042b (link)
#148984 chore: Update annotate-snippets to 0.12.9 561d7a8a23dbf0a1f1d7939b402639269019a139 (link)

previous master: 54f417673c

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

@Zalathar Zalathar deleted the rollup-n7hgioa branch November 16, 2025 06:56
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (67c4cf3): comparison URL.

Overall result: ❌ regressions - 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.

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

Max RSS (memory usage)

Results (primary 0.6%)

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

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

Cycles

Results (secondary -3.1%)

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)
- - 0
Improvements ✅
(secondary)
-3.1% [-3.5%, -2.4%] 3
All ❌✅ (primary) - - 0

Binary size

Results (primary -0.1%, secondary -0.1%)

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.1% [0.1%, 0.1%] 1
Improvements ✅
(primary)
-0.1% [-0.1%, -0.1%] 4
Improvements ✅
(secondary)
-0.1% [-0.1%, -0.1%] 34
All ❌✅ (primary) -0.1% [-0.1%, -0.1%] 4

Bootstrap: 475.059s -> 473.917s (-0.24%)
Artifact size: 388.65 MiB -> 388.65 MiB (0.00%)

@rustbot rustbot added the perf-regression Performance regression. label Nov 16, 2025
@Zalathar
Copy link
Member Author

The clap_derive result looks pretty clearly bimodal.

The secondary regressions are plausibly real, but don’t seem big enough to be worth investigating.

@panstromek
Copy link
Contributor

panstromek commented Nov 19, 2025

perf triage:

Marking as triaged based on the comment above

[edit]: include_blob is possibly also noise.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Nov 19, 2025
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-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant 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.