Rollup of 6 pull requests by JonathanBrouwer · Pull Request #154824 · rust-lang/rust

JonathanBrouwer · 2026-04-04T18:20:01Z

Successful merges:

[Debugger Visualizers] Optimize lookup behavior #147552 ([Debugger Visualizers] Optimize lookup behavior)
float: Fix panic at max exponential precision #154052 (float: Fix panic at max exponential precision)
fix compilation of time/hermit.rs #154706 (fix compilation of time/hermit.rs)
Make substr_range and subslice_range return the new Range type #154707 (Make substr_range and subslice_range return the new Range type)
triagebot: roll library reviewers for {coretests,alloctests} #154767 (triagebot: roll library reviewers for {coretests,alloctests})
bootstrap: Include shorthand aliases in x completions #154797 (bootstrap: Include shorthand aliases in x completions)

rust-lang#154518 has broken compiling std for Hermit by unwrapping an `i32`. This commit converts the `i32` to an `io::Result` before unwrapping.

Previously, `x d --<tab>` wouldn't show any options.

Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point). This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce02 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first. As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX. A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter. Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic. This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.

[Debugger Visualizers] Optimize lookup behavior # Background Almost all of the commands in `lldb_commands` used a regex to associate a type with the `synthetic_lookup` and `summary_lookup` python functions. When looking up a type, LLDB iterates through the commands in reverse order (so that new commands can overwrite old ones), stopping when it finds a match. These lookups are cached, but it's a shallow cache (e.g. when `Vec<T>` is matched by lldb, it will always point to `synthetic_lookup`, NOT the result of `synthetic_lookup` which would be `StdVecSyntheticProvider`). This becomes a problem because within `synthetic_lookup` and `summary_lookup` we run `classify_rust_type` which checks exact same regexes again. This causes 2 issues: 1. running the regexes via lldb commands is even more of a waste because the final check is a `.*` regex that associates with `synthetic_lookup` anyway 2. Every time lldb wants to display a value, that value must run the entirety of `synthetic_lookup` and run its type through 19 regexes + some assorted checks every single time. Those checks take between 1 and 100 microseconds depending on the type. On a 10,000 element `Vec<i32>` (which bypasses `classify_struct` and therefore the 19 regexes), ~30 milliseconds are spent on `classify_rust_type`. For a 10,000 element `Vec<UserDefinedStruct>` that jumps up to ~350 milliseconds. The salt on the wound is that some of those 19 regexes are useless (`BTreeMap` and `BTreeSet` which don't even have synthetic/summary providers so it doesn't matter if we know what type it is), and then the results of that lookup function use string-comparisons in a giant `if...elif...elif` chain. # Solution To fix all of that, the `lldb_commands` now point directly to their appropriate synthetic/summary when possible. In cases where there was extra logic, streamlined functions have been added that have much fewer types being passed in, thus only need to do one or two simple checks (e.g. `classify_hashmap` and `classify_hashset`). Some of the `lldb_commands` regexes were also consolidated to reduce the total number of commands we pass to lldb (e.g. `NonZero` An extra upshot is that `summary_lookup` could be completely removed due to being redundant.

…r=Mark-Simulacrum float: Fix panic at max exponential precision Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point). This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce02 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first. As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX. A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter. Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic. This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.

@Mark-Simulacrum

…lacrum fix compilation of time/hermit.rs rust-lang#154518 has broken compiling std for Hermit by unwrapping an `i32`. This PR converts the `i32` to an `io::Result` before unwrapping. Closes rust-lang#154626. Closes hermit-os/hermit-rs#965. r? @Mark-Simulacrum

…rk-Simulacrum Make `substr_range` and `subslice_range` return the new `Range` type Makes the unstable `substr_slice` and `substr_range` functions return the new `core::range::Range` type, instead of the old `core::ops::Range`. Unblocks the [stabilization](rust-lang#141266) of `#![feature(substr_range)]`, see rust-lang#141266 (comment)

triagebot: roll library reviewers for `{coretests,alloctests}` Noticed in rust-lang#154761 that we are currently rolling fallback reviewers for `library/{alloctests,coretests}` r? libs

…ulacrum bootstrap: Include shorthand aliases in x completions Previously, `x d --<tab>` wouldn't show any options.

JonathanBrouwer · 2026-04-04T18:20:13Z

@bors r+ rollup=never p=5

rust-bors · 2026-04-04T18:20:16Z

📌 Commit 9f07f8b has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-04-04T18:20:21Z

Trying commonly failed jobs
@bors try jobs=dist-various-1,test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple,x86_64-mingw-1

Rollup of 6 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1

rust-bors · 2026-04-04T21:18:39Z

☀️ Try build successful (CI)
Build commit: bb0a52d (bb0a52d1febcd34d0140b4c293f677915b81f9a7, parent: 0312a55fe4200208170b94bf287ca3cc7ea499ae)

rust-bors · 2026-04-05T00:08:10Z

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 7m 36s
Pushing 4e83686 to main...

rust-timer · 2026-04-05T00:09:52Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#147552	[Debugger Visualizers] Optimize lookup behavior	`0795a234b8c14a69e8a2353fff4331463a4ad14b` (link)
#154052	float: Fix panic at max exponential precision	`1b87ec1c6d575f0b4f772973f5a8c460ce8fa430` (link)
#154706	fix compilation of time/hermit.rs	`17b3f93bbfb16f9a9e6f4ddcb2f7681196e1d87c` (link)
#154707	Make `substr_range` and `subslice_range` return the new `Ra…	`489d104a43779a0a2f7d3e3389160a8b306cb100` (link)
#154767	triagebot: roll library reviewers for `{coretests,alloctest…	`070604a3730177bcb411eda36fab30a315f8fc66` (link)
#154797	bootstrap: Include shorthand aliases in x completions	`9a56b6600883ea665efe774c5bcc8af7c4156450` (link)

previous master: e0e95a7187

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

github-actions · 2026-04-05T00:11:02Z

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 e0e95a7 (parent) -> 4e83686 (this PR)

Test differences

Show 92 test diffs

Stage 1

fmt::float::test_format_f64_max_precision_exponential: [missing] -> pass (J1)

Stage 2

fmt::float::test_format_f64_max_precision_exponential: [missing] -> pass (J0)

Additionally, 90 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 4e836866b57c1d92c1b747d524cd04ba0f55ea3a --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

dist-i686-mingw: 2h 4m -> 2h 41m (+29.8%)
x86_64-gnu-llvm-21-2: 1h 38m -> 1h 24m (-14.4%)
pr-check-1: 33m 14s -> 28m 31s (-14.2%)
i686-gnu-2: 1h 43m -> 1h 29m (-13.6%)
x86_64-gnu-llvm-21-3: 1h 55m -> 1h 40m (-13.0%)
x86_64-gnu-llvm-22-2: 1h 40m -> 1h 27m (-12.8%)
dist-x86_64-msvc-alt: 2h 31m -> 2h 50m (+12.7%)
i686-gnu-1: 2h 26m -> 2h 8m (-12.3%)
pr-check-2: 43m 29s -> 38m 22s (-11.8%)
x86_64-msvc-1: 2h 48m -> 2h 29m (-11.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-log-analyzer · 2026-04-05T00:37:01Z

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

  COMMIT_MESSAGE: cargo update 
##[endgroup]
Downloading single artifact
Preparing to download the following artifacts:
- Cargo-lock (ID: 6274067731, Size: 50848, Expected Digest: sha256:6114e3c6a43e91798fe2ce24456d1b747a311ed41f2ee7065bf548bbad7a7357)
Redirecting to blob download url: https://productionresultssa14.blob.core.windows.net/actions-results/0b6b667b-f6ac-4927-add5-c36a5789b71a/workflow-job-run-e299b616-18a0-5e6a-b713-63fba94c685b/artifacts/858175980ba8726bab9f963fd06060d5199d874bbd735e523e2d990d354f8c0b.zip
Starting download of artifact to: /home/runner/work/rust/rust
(node:2268) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
SHA256 digest of downloaded artifact is 6114e3c6a43e91798fe2ce24456d1b747a311ed41f2ee7065bf548bbad7a7357
Artifact download completed successfully.
Total of 1 artifact(s) downloaded
Download artifact has finished successfully
---
  COMMIT_MESSAGE: cargo update 
##[endgroup]
Downloading single artifact
Preparing to download the following artifacts:
- cargo-updates (ID: 6274067771, Size: 2960, Expected Digest: sha256:97eb6102f7d255c7ea23d80b1bc9f6d391eb65fca84af2c52d3e7db6f96573bc)
Redirecting to blob download url: https://productionresultssa14.blob.core.windows.net/actions-results/0b6b667b-f6ac-4927-add5-c36a5789b71a/workflow-job-run-e299b616-18a0-5e6a-b713-63fba94c685b/artifacts/ce9034d4568b3430f906da1368ae1cf3e14ef1542859eb2e8d635c0876371f53.zip
Starting download of artifact to: /home/runner/work/rust/rust
(node:2282) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
SHA256 digest of downloaded artifact is 97eb6102f7d255c7ea23d80b1bc9f6d391eb65fca84af2c52d3e7db6f96573bc
Artifact download completed successfully.
Total of 1 artifact(s) downloaded
Download artifact has finished successfully
##[group]Run echo "${COMMIT_MESSAGE}" > commit.txt
echo "${COMMIT_MESSAGE}" > commit.txt
cat cargo_update.log >> commit.txt

echo "${PR_MESSAGE}" > body.md
echo '```txt' >> body.md
cat cargo_update.log >> body.md
echo '```' >> body.md
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
---
dep-bumps
following is the output from `cargo update`:
  COMMIT_MESSAGE: cargo update 
##[endgroup]
##[group]Run git config user.name github-actions
git config user.name github-actions
git config user.email github-actions@github.com
git switch --force-create cargo_update
git add ./Cargo.lock ./library/Cargo.lock ./src/tools/rustbook/Cargo.lock
git commit --no-verify --file=commit.txt
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
---
dep-bumps
following is the output from `cargo update`:
  COMMIT_MESSAGE: cargo update 
##[endgroup]
remote: error: GH006: Protected branch update failed for refs/heads/cargo_update.        
remote: 
remote: - Cannot force-push to this branch        
To https://github.com/rust-lang/rust
 ! [remote rejected]   cargo_update -> cargo_update (protected branch hook declined)
error: failed to push some refs to 'https://github.com/rust-lang/rust'
##[error]Process completed with exit code 1.
Post job cleanup.

rust-timer · 2026-04-05T00:50:09Z

Finished benchmarking commit (4e83686): 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.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.3%, 0.3%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	3
All ❌✅ (primary)	0.3%	[0.3%, 0.3%]	4

Max RSS (memory usage)

Results (primary -0.5%, 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)	1.3%	[1.3%, 1.3%]	1
Regressions ❌ (secondary)	3.4%	[2.1%, 4.2%]	4
Improvements ✅ (primary)	-2.3%	[-2.3%, -2.3%]	1
Improvements ✅ (secondary)	-2.9%	[-4.5%, -1.0%]	5
All ❌✅ (primary)	-0.5%	[-2.3%, 1.3%]	2

Cycles

Results (primary -3.3%, secondary 0.8%)

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)	4.3%	[4.3%, 4.3%]	1
Improvements ✅ (primary)	-3.3%	[-3.3%, -3.3%]	1
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	-3.3%	[-3.3%, -3.3%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 489.285s -> 488.015s (-0.26%)
Artifact size: 395.03 MiB -> 395.10 MiB (0.02%)

Mark-Simulacrum · 2026-04-06T12:14:52Z

Looks like noise on both improvements and regressions to me.

Walnut356 and others added 16 commits March 31, 2026 05:01

change RustType from string literals to enum

623c7d7

remove unnecessary regex usage

9e39de9

use direct providers when possible

b17670d

fix tests

eca09de

fix compilation of time/hermit.rs

3d55f38

rust-lang#154518 has broken compiling std for Hermit by unwrapping an `i32`. This commit converts the `i32` to an `io::Result` before unwrapping.

Make substr_range and subslice_range return the new Range type

8b06612

directly point to tuple summary

3c52bb5

triagebot: roll library reviewers for {coretests,alloctests}

d5f67d8

bootstrap: Include shorthand aliases in x completions

91e4524

Previously, `x d --<tab>` wouldn't show any options.

Rollup merge of rust-lang#154767 - jieyouxu:lib-tests, r=Mark-Simulacrum

1bc6b6a

triagebot: roll library reviewers for `{coretests,alloctests}` Noticed in rust-lang#154761 that we are currently rolling fallback reviewers for `library/{alloctests,coretests}` r? libs

Rollup merge of rust-lang#154797 - jyn514:jyn/completions, r=Mark-Sim…

9f07f8b

…ulacrum bootstrap: Include shorthand aliases in x completions Previously, `x d --<tab>` wouldn't show any options.

rust-bors bot added the rollup A PR which is a rollup label Apr 4, 2026

rust-bors bot 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 Apr 4, 2026

This comment has been minimized.

Sign in to view

rust-bors bot 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 Apr 5, 2026

rust-bors bot merged commit 4e83686 into rust-lang:main Apr 5, 2026
13 checks passed

rustbot added this to the 1.96.0 milestone Apr 5, 2026

rustbot added the perf-regression Performance regression. label Apr 5, 2026

Mark-Simulacrum removed the perf-regression Performance regression. label Apr 6, 2026

Uh oh!

Conversation

JonathanBrouwer commented Apr 4, 2026

Uh oh!

JonathanBrouwer commented Apr 4, 2026

Uh oh!

rust-bors bot commented Apr 4, 2026

Uh oh!

JonathanBrouwer commented Apr 4, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Apr 4, 2026

Uh oh!

rust-bors bot commented Apr 5, 2026

Uh oh!

Uh oh!

rust-timer commented Apr 5, 2026

Uh oh!

github-actions bot commented Apr 5, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-log-analyzer commented Apr 5, 2026

Uh oh!

rust-timer commented Apr 5, 2026

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

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Mark-Simulacrum commented Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants