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.

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. 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.