Update unexpected_cfgs lint for Cargo new check-cfg config

[Urgau]

This PR updates the diagnostics output of the unexpected_cfgs lint for Cargo new check-cfg config.

It's a simple and cost-less alternative to the build-script cargo::rustc-check-cfg instruction.

[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] }

This PR also adds a Cargo specific section regarding check-cfg and Cargo inside rustc's book (motivation is described inside the file, but mainly check-cfg is a rustc feature not a Cargo one, Cargo only enabled the feature, it does not own it; T-cargo even considers the check-cfg lint config to be an implementation detail).

This PR also updates the links to refer to that sub-page when using Cargo from rustc.

As well as updating the lint doc to refer to the check-cfg docs.

Not to be merged before rust-lang/cargo#13913 reaches master! (EDIT: merged in #125237)

@rustbot label +F-check-cfg
r? @fmease (feel free to roll)
Fixes #124800
cc @epage @weihanglo

[epage]

When I suggested this go into the check-cfg docs, it was with the assumption that it was to be an additional note that built on existing knowledge. I also didn't realize there was a separate section for this and thought it would be in the lint docs.

Personally, what I recommend is

• Update the lint docs to point to the check-cfg docs so users can discover how to customize things
• Soon after It has this basic form: in the check-cfg docs, have an addendum that this can also be set in build.rs (link to the directive's docs) and lint config (show a short example)

[Urgau]

Update the lint docs to point to the check-cfg docs so users can discover how to customize things

That is indeed something we should do. I will do that in this PR.

Soon after It has this basic form: in the check-cfg docs, have an addendum that this can also be set in build.rs (link to the directive's docs) and lint config (show a short example)

I would rather prefer if we not do that. That section is specifically for the --check-cfg flag and adding in the middle of it some cargo knowledge seems out place, in particular since Cargo is not the build system that uses --check-cfg.

In general I would really prefer to keep the current --check-cfg doc as is, that's why I propose to add a small "sub-page" dedicated to those Cargo specificity so that 1. we can easily link to it and 2. so that users of Cargo are not overwhelm with all the technicalities of the --check-cfg flag when they only care about Cargo (at first at least).

[Urgau]

I just updated the lint documentation to refer to the check-cfg docs.

[fmease]

Thanks for the PR!

Personally speaking – not on behalf of T-compiler-contributors —, I'm quite wary / skeptical about adding such a Cargo-specific chapter to the rustc book. While it's very nicely written, one could be fooled into believing it was a page from the Cargo book.

I see where T-cargo is coming from in regards to “it's an implementation detail” I agree with T-cargo that the format of check-cfg is an implementation detail from Cargo's POV but the way the docs are split up right now in this PR seems less than ideal to me.

I'm willing to approve this PR with its current overall structure (i.e., after the smaller nits I picked have been addressed) because we want to promote Cargo's new way to configure the cfgs as soon as possible I suppose.

However, I'd rather keep Cargo-specific explainers that are as long as this one out of the rustc book. It should be possible to rephrase the relevant chapters in the Cargo book (build scripts & lint tables) in such a way that it's obvious what is part of Cargo's API and what is rustc-specific without degrading the quality of docs (by linking to the rustc book where necessary, by disclaiming for example that any examples that are provided are not guaranteed to be valid according to rustc and merely serve as an example, etc.).

[Urgau]

I fixed the nits and reduced the doc changes to the minimal, with only a small description, a link to relevant page and a small example for the each of the 3 ways.

@rustbot ready

[fmease]

@bors r+ rollup

[bors]

📌 Commit ccd3e99 has been approved by fmease

It is now in the queue for this repository.

[matthiaskrgr]

@bors rollup=iffy

[epage]

Personally speaking – not on behalf of T-compiler-contributors —, I'm quite wary / skeptical about adding such a Cargo-specific chapter to the rustc book. While it's very nicely written, one could be fooled into believing it was a page from the Cargo book.

I agree that the framing of this feels out of place in rustc. When I suggested putting content here, the intent was to be very limited, to only say that the --check-cfg flag can also be set through lints and build.rs and leave it at that. See #125219 (comment)

[fmease]

@bors p=1 check-cfg is trigger-happy and we should provide up-to-date information

[bors]

⌛ Testing commit ccd3e99 with merge b92758a...

[bors]

☀️ Test successful - checks-actions
Approved by: fmease
Pushing b92758a to master...

[rust-timer]

Finished benchmarking commit (b92758a): 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)	0.8%	[0.2%, 2.5%]	21
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.8%	[0.2%, 2.5%]	21

Max RSS (memory usage)

Results (primary -1.8%, secondary 4.5%)

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

Cycles

Results (primary 1.8%)

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.8%	[1.4%, 2.2%]	4
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.8%	[1.4%, 2.2%]	4

Binary size

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

Bootstrap: 672.136s -> 670.311s (-0.27%)
Artifact size: 316.17 MiB -> 315.45 MiB (-0.23%)

[Urgau]

I think the perf regressions are the result of adding one more note in the diagnostic output, which is trigger happy on many compile benchmark from rustc-perf. cc #124684 (comment)

[rylev]

Seems like we're likely ok with such regressions when they're in the "unhappy path".

@rustbot label: +perf-regression-triaged