Update cargo

[Muscraft]

18 commits in 6087566b3fa73bfda29702632493e938b12d19e5..05364cb2f61a2c2b091e061c1f42b207dfb5f81f
2024-04-30 20:45:20 +0000 to 2024-05-03 16:48:59 +0000

• chore(deps): update msrv (3 versions) to v1.76 (chore(deps): update msrv (3 versions) to v1.76 cargo#13857)
• Stabilize -Zcheck-cfg as always enabled (Stabilize -Zcheck-cfg as always enabled cargo#13571)
• fix(lints): Prevent inheritance from bring exposed for published packages (fix(lints): Prevent inheritance from bring exposed for published packages cargo#13852)
• refactor: remove unnecessary branch for link binary on macOS (refactor: remove unnecessary branch for link binary on macOS cargo#13851)
• perf(toml): Avoid inferring when targets are known (perf(toml): Avoid inferring when targets are known cargo#13849)
• Update continuous-integration.md: Include CircleCI reference (Update continuous-integration.md: Include CircleCI reference cargo#13850)
• chore(deps): update msrv (1 version) to v1.78 (chore(deps): update msrv (1 version) to v1.78 cargo#13848)
• Workaround copying file returning EAGAIN on ZFS on mac OS (Workaround copying file returning EAGAIN on ZFS on mac OS cargo#13845)
• Clean package perf improvements (Clean package perf improvements cargo#13818)
• fix(toml): Validate crates_types/proc-macro for bin like others (fix(toml): Validate crates_types/proc-macro for bin like others  cargo#13841)
• fix(toml): On 2024 Edition, disallow ignored default-features when inheriting (fix(toml): On 2024 Edition, disallow ignored default-features when inheriting cargo#13839)
• chore(ci): Ignore openssl deps (chore(ci): Ignore openssl deps cargo#13840)
• fix(lints): Remove ability to specify - in lint name (fix(lints): Remove ability to specify - in lint name cargo#13837)
• fix(resolver): Treat unset MSRV as compatible (fix(resolver): Treat unset MSRV as compatible cargo#13791)
• fix(toml): Don't lose 'public' when inheriting a dep (fix(toml): Don't lose 'public' when inheriting a dep  cargo#13836)
• chore(deps): update compatible (chore(deps): update compatible cargo#13834)
• Error when unstable lints are specified but not enabled (Error when unstable lints are specified but not enabled cargo#13805)
• fix(lint): Warn not Error on unsupported lint tool (fix(lint): Warn not Error on unsupported lint tool cargo#13833)

r? ghost

Note: this includes the fix that was beta backported in #124647

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

[Muscraft]

@bors r+ rollup=never p=1

[bors]

📌 Commit 8644cf9 has been approved by Muscraft

It is now in the queue for this repository.

[bors]

⌛ Testing commit 8644cf9 with merge f50f99b...

[rust-log-analyzer]

The job aarch64-gnu failed! Check out the build log: (web) (plain)

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

[TIMING] core::build_steps::compile::Sysroot { compiler: Compiler { stage: 0, host: aarch64-unknown-linux-gnu }, force_recompile: false } -- 0.000
[TIMING] core::builder::Builder::sysroot_libdir::Libdir { compiler: Compiler { stage: 0, host: aarch64-unknown-linux-gnu }, target: aarch64-unknown-linux-gnu } -- 0.001
##[group]Building stage0 tool tidy (aarch64-unknown-linux-gnu)

##[error]The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.
Session terminated, killing shell...::group::Clock drift check
  network time: Sat, 04 May 2024 00:02:02 GMT
##[endgroup]
    Updating crates.io index

[bors]

💔 Test failed - checks-actions

[Muscraft]

I'm not sure what caused the error.

@bors retry rollup=never p=1

[bors]

⌛ Testing commit 8644cf9 with merge 2c4bf24...

[bors]

☀️ Test successful - checks-actions
Approved by: Muscraft
Pushing 2c4bf24 to master...

[rust-timer]

Finished benchmarking commit (2c4bf24): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	2.4%	[0.2%, 19.1%]	83
Regressions ❌ (secondary)	1.6%	[0.2%, 5.7%]	92
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[0.2%, 19.1%]	83

Max RSS (memory usage)

Results

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)	3.0%	[0.6%, 5.8%]	40
Regressions ❌ (secondary)	4.6%	[2.1%, 7.7%]	22
Improvements ✅ (primary)	-1.5%	[-1.5%, -1.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.9%	[-1.5%, 5.8%]	41

Cycles

Results

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)	4.2%	[0.9%, 12.9%]	27
Regressions ❌ (secondary)	2.8%	[0.9%, 5.2%]	29
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.2%	[0.9%, 12.9%]	27

Binary size

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

Bootstrap: 678.263s -> 675.159s (-0.46%)
Artifact size: 315.83 MiB -> 315.86 MiB (0.01%)

[weihanglo]

With the --check-cfg always on, it is expected to have a slight drop around ~1% (see #97657 (comment). However this regression is way huger than that.

We also have some dependencies updates in this PR so unsure which is the culprit. Continue investigating...

[Urgau]

I'm highly suspicious the perf regressions have the same cause as in #120393, the sheer number of warnings we now emit. In #120393 (comment) we had ~200 warnings and that caused us ~3/4% perf on diesel, diesel isn't impacted here but the same reasoning can be applied here to syn, our biggest regression.

The syn build now produces 1800 warnings with only an handful of them not coming from the unexpected_cfgs lint (the --check-cfg lint).

In summary, this may not be a "real" perf regression after all, just a deficiency in our perf tests that is no longer measuring the same thing as before.

I'm having trouble confirming this locally but I'm pretty sure those warnings account for the vast majority (if not all) of the perf regressions.

[Kobzol]

I didn't have a chance to investigate this yet, but based on the self-profile data, it indeed looks like much more time is spent in the lint machinery.

[ehuss]

I'm not sure what caused the error.

@Muscraft The aarch64-gnu is frequently killed for various reasons. It is a self-hosted runner and is thus a little more sensitive to being restarted. You can see the reason in the "Summary" page on GitHub Actions, and scrolling down to see:

The runner has received a shutdown signal. This can happen when the runner service is stopped, or a manually started runner is canceled.

That is always out of our control, and just needs to be retried.

[nnethercote]

Why are there so many new warnings?

[weihanglo]

@nnethercote unexpected_cfgs lint is trigged because Cargo now passes --check-cfg flag.

See rust-lang/blog.rust-lang.org#1313, which is supposed to be out along with the nightly release 😂.

[nnethercote]

Why do the benchmarks trigger so many occurrences of these new warnings? Is that typical? Are lots of crates now getting hundreds of new warnings?

[weihanglo]

Are lots of crates now getting hundreds of new warnings?

You local crates with lots of custom cfg will get lots of warnings. But none of them will come from transitive dependencies, as Cargo uses --cap-lints. Only warnings from local crates will get generated.

[pnkfelix]

I believe the hypothesis that the regression being flagged here is an artifact of the increase in number-of-warnings being emitted. I consider this a (mostly-)false alarm resulting as an artifact of design decisions in our rustc-perf infrastructure. (I say "mostly-false" since I do think that @nnethercote is asking the right question, namely about whether other crates should be expecting to see a similar explosion in lint output.)

cc rust-lang/rustc-perf#1819

marking as triaged

@rustbot label: +perf-regression-triaged

[Urgau]

@pnkfelix Part of the regressions is also the loading of all the built-ins targets to populate the well known cfgs (in particular all the target_* cfgs), I did a measurement some time ago about the impact of loading those and it was mostly: [+0.31%, +2.17%] +0.81%.

The reason why loading all the built-ins targets is expensive is because they are unfortunately not immutable, both in terms of data, like Apple targets who at runtime look at some env variables but also in terms of heap allocations; and while individually it's not much, multiplied by more than 280 targets it's adding up quickly.

I have a PR #122703 in the works to reduce to the bare minimum this cost, and it's showing some results #122703 (comment): [-2.18%, -0.21%] -0.91%.