Weekly cargo update

[github-actions]

Automation to keep dependencies in Cargo.lock current.
r? dep-bumps

The following is the output from cargo update:

compiler & tools dependencies:
     Locking 3 packages to latest compatible versions
    Updating ipc-channel v0.20.0 -> v0.20.1
    Updating rand v0.9.1 -> v0.9.2
    Updating redox_syscall v0.5.13 -> v0.5.16
note: pass `--verbose` to see 37 unchanged dependencies behind latest

library dependencies:
     Locking 1 package to latest compatible version
    Updating rand v0.9.1 -> v0.9.2
note: pass `--verbose` to see 2 unchanged dependencies behind latest

rustbook dependencies:
     Locking 1 package to latest compatible version
    Updating redox_syscall v0.5.13 -> v0.5.16

[rustbot]

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[clubby789]

@bors r+ rollup=never

[bors]

📌 Commit 75420b6 has been approved by clubby789

It is now in the queue for this repository.

[bors]

⌛ Testing commit 75420b6 with merge cdccba8...

[samueltardieu]

bors r+ rollup=never

Just out of curiosity, and to educate myself, wouldn't iffy be more appropriate in such a case? Is there really a chance that such a PR would be rolled back and needs to be run is isolation?

I'm wondering because I've just queued a rollup that will likely run right after the current PR (which has the floor right now), but I would have included it in the rollup if it was iffy as no other PR in the rollup touches the same lock files.

[bors]

☀️ Test successful - checks-actions
Approved by: clubby789
Pushing cdccba8 to master...

[github-actions]

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 498ae9f (parent) -> cdccba8 (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard cdccba87bf9ad5d87c1417eeb8fa52a4b614bbf9 --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. x86_64-apple-2: 3216.6s -> 6410.1s (99.3%)
2. dist-powerpc64-linux: 5118.3s -> 8091.2s (58.1%)
3. dist-aarch64-linux: 5884.1s -> 8121.4s (38.0%)
4. x86_64-apple-1: 6531.7s -> 8932.5s (36.8%)
5. pr-check-2: 2128.3s -> 2737.7s (28.6%)
6. dist-aarch64-apple: 7257.6s -> 5347.9s (-26.3%)
7. x86_64-gnu-llvm-19: 2456.9s -> 2877.1s (17.1%)
8. dist-apple-various: 6398.5s -> 7454.4s (16.5%)
9. dist-x86_64-apple: 10371.6s -> 8685.0s (-16.3%)
10. pr-check-1: 1537.7s -> 1781.9s (15.9%)

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]

Finished benchmarking commit (cdccba8): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary -1.5%)

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

Cycles

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

Binary size

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

Bootstrap: 468.807s -> 469.046s (0.05%)
Artifact size: 376.77 MiB -> 376.81 MiB (0.01%)

[clubby789]

Just out of curiosity, and to educate myself, wouldn't iffy be more appropriate in such a case? Is there really a chance that such a PR would be rolled back and needs to be run is isolation?

Iffy might be more appropriate - previously these used to fail almost every time, but are a little more stable now.