Run cargo update in the project root

[tgross35]

try-job: x86_64-msvc

Part of #129538

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

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

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

[tgross35]

Running a try job because of #127890

@bors try

[bors]

⌛ Trying commit 95a0761 with merge fd4dc52...

[tgross35]

@bors try

[bors]

⌛ Trying commit 95a0761 with merge bf3d3ef...

[bors]

💔 Test failed - checks-actions

[tgross35]

Hm. I assume this comes from stacker making a change that brings in windows-sys 0.36.1, which is quite a bit older than the other versions we use

[tgross35]

@nagisa it looks like you maintain https://github.com/rust-lang/stacker, any clue if this is related?

[nagisa]

Sounds plausible enough. There's already a PR that bumps it on stacker side, so you'll be able to check this soon enough.

[tgross35]

Okay, I dropped doing a cargo update in the root repo. Let's try again.

@bors try

[bors]

⌛ Trying commit 47c2f97 with merge 60d700d...

[bors]

☀️ Try build successful - checks-actions
Build commit: 60d700d (60d700d5439dd91cf6ad2fd0616f3eb6afe7fe4f)

[bors]

☔ The latest upstream changes (presumably #130807) made this pull request unmergeable. Please resolve the merge conflicts.

[tgross35]

I dropped the library and rustbook changes from this PR, so updates are now spread across a couple smaller PRs:

• project root: this one
• rustbook: Weekly cargo update: only rustbook #130889
• most of library: Partially update library/Cargo.lock #130892
• library cc: Bump cc dependency #130720, Bump cc dependency #130898 (experiments)
• library compiler-builtins: update compiler-builtins to 0.1.126 #130875
• memchr (done): Pin memchr to 2.5.0 in the library rather than rustc_ast #130788

Hoping that the MSVC failures isolate themselves to only a subset of these PRs.

@bors r=Mark-Simulacrum

[bors]

📌 Commit 1760d39 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1760d39 with merge 2bd1e89...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 2bd1e89 to master...

[workingjubilee]

miraculous

[tgross35]

I guess we have some pretty likely indicators that the library cc update in particular is causing the near-100% failure rate in these PRs. Why exactly, that's an interesting question...

[ChrisDenton]

I'll try to see if anything in cc looks like it might cause problems. It's maybe a long shot though.

[tgross35]

I'm trying to see if there is a specific cc version where the awful rate starts or if it just seems to be any change. #130898 only bumps to 1.0.106 and has failed twice, I'm trying 1.0.100 (smallest possible bump) in #130908.

[rust-timer]

Finished benchmarking commit (2bd1e89): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.5%	[-1.2%, -0.1%]	14
Improvements ✅ (secondary)	-1.0%	[-2.5%, -0.2%]	7
All ❌✅ (primary)	-0.5%	[-1.2%, -0.1%]	14

Max RSS (memory usage)

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

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: 772.536s -> 774.091s (0.20%)
Artifact size: 340.88 MiB -> 341.36 MiB (0.14%)

[arttet]

I'll try to see if anything in cc looks like it might cause problems. It's maybe a long shot though.

@ChrisDenton, please look at this commit. It seems it is suspicious.

[ChrisDenton]

That makes no practical difference. All DLLs are unloaded on process exit.