Update the cc crate for rustc_llvm

[bjorn3]

Latest stacker needs a newer cc than 1.2.16 as older versions don't have windows arm64ec support.

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

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Mark-Simulacrum

[bjorn3]

Given that the previous attempt regressed performance:

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: f61a781 (f61a781aa926b40af32168929f416c41f07e54b3, parent: 27dbdb57a2f90b5c90247e6ef14f2657a03473da)

[rust-timer]

Finished benchmarking commit (f61a781): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

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.7%	[0.4%, 3.4%]	247
Regressions ❌ (secondary)	0.9%	[0.0%, 2.7%]	289
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.4%, 3.4%]	247

Max RSS (memory usage)

Results (primary -0.0%, secondary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.5%	[1.5%, 1.5%]	1
Regressions ❌ (secondary)	2.4%	[2.2%, 2.6%]	2
Improvements ✅ (primary)	-1.6%	[-1.6%, -1.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-1.6%, 1.5%]	2

Cycles

Results (secondary -2.2%)

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)	-2.2%	[-2.2%, -2.1%]	2
All ❌✅ (primary)	-	-	0

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.301s -> 492.119s (0.37%)
Artifact size: 394.23 MiB -> 393.76 MiB (-0.12%)

[Mark-Simulacrum]

I think we need an explanation if not necessarily a solution (though those regressions look rather large, including on full builds).

@rustbot author

[ChrisDenton]

The nearest to an explanation seems to be #146186 (comment), cc @madsmtm

It would be a bit of a problem if we can never upgrade cc-rs again...

[madsmtm]

I never got further than that investigation unfortunately