Weekly cargo update

[github-actions]

Automation to keep dependencies in Cargo.lock current.

The following is the output from cargo update:

compiler & tools dependencies:
     Locking 8 packages to latest compatible versions
    Updating anyhow v1.0.94 -> v1.0.95
    Updating glob v0.3.1 -> v0.3.2
    Updating quote v1.0.37 -> v1.0.38
    Updating rustversion v1.0.18 -> v1.0.19
    Updating serde v1.0.216 -> v1.0.217
    Updating serde_derive v1.0.216 -> v1.0.217
    Updating syn v2.0.90 -> v2.0.93
    Updating unicase v2.8.0 -> v2.8.1
note: pass `--verbose` to see 36 unchanged dependencies behind latest

library dependencies:
     Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 5 unchanged dependencies behind latest

rustbook dependencies:
     Locking 7 packages to latest compatible versions
    Updating anyhow v1.0.94 -> v1.0.95
    Updating cc v1.2.5 -> v1.2.6
    Updating quote v1.0.37 -> v1.0.38
    Updating serde v1.0.216 -> v1.0.217
    Updating serde_derive v1.0.216 -> v1.0.217
    Updating syn v2.0.90 -> v2.0.93
    Updating unicase v2.8.0 -> v2.8.1

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

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]

Hm, we probably want to lock cc for rustbook too. For now this pulls in rust-lang/cc-rs#1330 only, which should be fine:tm:

@bors r+ rollup=never

[bors]

📌 Commit 519c233 has been approved by clubby789

It is now in the queue for this repository.

[bors]

⌛ Testing commit 519c233 with merge 480eec0692f003c9d8bd477ee867f2f66643bc04...

[bors]

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

[rust-timer]

Finished benchmarking commit (480eec0): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary 1.7%, secondary -0.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

Results (secondary -1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

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

Bootstrap: 763.48s -> 762.977s (-0.07%)
Artifact size: 325.50 MiB -> 325.48 MiB (-0.01%)

[klensy]

Renovate #134071 looks dead? Or i missed some prs.