Stabilize -Zcheck-cfg as always enabled

[Urgau]

This PR stabilize the -Zcheck-cfg option as always enabled.

Waiting on rust-lang/rust#82450 (comment) to complete, but is otherwise ready to be reviewed (in particular the documentation changes). (rust-lang/rust#123501)

Fixes #10554

[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

[bors]

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

[bors]

⌛ Testing commit 388a17f with merge 7ebc065...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 7ebc065 to master...

[Darksonn]

Would it make sense to add some common --cfg names from the ecosystem such as #[cfg(loom)] to the allow-list?

[epage]

Its a bit difficult to decide what is "common" enough to justify inclusion and what level of compatibility we should provide on these. For now, we are sticking with cfg's that are first-party to cargo.

Something like https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618 would allow registering more configs with Cargo in a declarative manner.

It is unfortunate that hyper and tokio are disabling the lint to avoid the overhead of build scripts

• chore: fix unexpected cfg warning hyperium/hyper#3660
• Bump nightly to nightly-2024-05-05 tokio-rs/tokio#6538

Tokio at least has a custom CI job where they check it. I guess another alternative is a config file with the rustflags set though I always find that annoying when contributing to repos due to my personal workflow.

[Darksonn]

I understand that including third-party --cfgs is a bit of a can of worms. But I also think that it would significantly reduce the amount of crates that are going to have to silence the lint. You could consider doing a crater run to figure out which flags are common?

In Tokio's case, there's probably no way around disabling it. We use too many --cfg flags for various bespoke ways of configuring the test suite. Making them into features will not work. Build scripts hurt compile times for end users, and rustflags is a bad experience for new contributors. I think that having a dedicated CI run that enables the lint is reasonable compromise.

[Urgau]

You could consider doing a crater run to figure out which flags are common?

We did, you can see the results here: rust-lang/rust#120701 (comment)

Deciding what is common enough is difficult since every use-case can be vastly different, the Rust-for-Linux project probably don't want your loom cfg in their build system.

In the stabilization report of --check-cfg I proposed a simple rule for what is constitute a well known cfg, it must be set by a Rust Toolchain tool since that is the least common denominator for all users, everything else is not a well known cfg.

[kennykerr]

Looks like I'll also have to silence the warning: microsoft/windows-rs#3022

[Thomasdezeeuw]

I want to reiterate that this creates an issue and a lot of churn for crates that have valid cfg attributes outside of the "expected" list.

Would it be possible for the code itself to define a list of correct (additional) attributes? To give a concrete example, Mio uses two cfg attributes to force a specific implementations. It would be nice if we could add something like the following to our code so that Rust can safe ignore the warnings.

#![expected_cfgs(mio_unsupported_force_poll_poll, mio_unsupported_force_waker_pipe)]

I think this would also solve the "common third party" issue as Loom (and other crates) could recommend to put something like the above into the users code.

[ChrisDenton]

See also rust-lang/rust#124800. It's probably best to keep the discussion in one place.