Announce automatic checking of cfgs at compile-time

[Urgau]

This blog post announce automatic checking of cfgs at compile-time (https://github.com/rust-lang/rfcs/pull/3013) by the Cargo (and Compiler) team.

To be merged when https://github.com/rust-lang/cargo/pull/13571 (status: merged in Cargo) reaches nightly.

Currently scheduled for 2024-05-05.

[weihanglo]

https://github.com/rust-lang/rust/pull/124684 was just merged, so the next nightly (nightly-2024-05-05 presumably) will include the change.

[Urgau]

I've tested the latest nightly and it produces the right warnings. I also updated the diagnostics output to the latest update. This is now ready to be merged.

[apoelstra]

This post is emphatic that you can't disable this without a build.rs, but you can, by adding #![allow(unexpected_cfgs] to your lib.rs or main.rs.

I think this is worth saying and would greatly reduce the amount of blowback from this change.

[Urgau]

Let's not derail this PR but it is written under "Frequently asked questions":

Can it be disabled?

For Cargo users, the feature is always on and cannot be disabled, but like any other lints it can be controlled: #![warn(unexpected_cfgs)].

[apoelstra]

@Urgau I read the existing text, and I believe it is misleading. It says "cannot be disabled" with "cannot" emphasized, and shows how to make it a warning. A reader needs to infer that "cannot" is actually wrong and that you can change warn to allow to disable the lint.

Furthermore, later in the post there is a FAQ entry about being able to disable the lint without build.rs, and again the text explicitly says that you can't do it.

BTW, if it is "derailing the PR" to comment on the text of the blog post that this PR adds, then where are comments supposed to be posted?

[Urgau]

I see allowing the lint as disabling the effect of the feature but the feature is still there, Cargo is still passing the --check-cfg args to rustc, you can still use cargo::rustc-check-cfg in build.rs, if you do cargo check -v they will still show up.

As for writing warn and not allow in the blog post, there is two reasons, the first is to be consistent with the note emitted by the compiler (as shown in the image) and the second is to avoid users just copy/pasting the example without looking at their warnings first. I understand this is not ideal, but I really want to avoid users allowing the lint instead of fixing the warnings.

---

BTW, if it is "derailing the PR" to comment on the text of the blog post that this PR adds, then where are comments supposed to be posted?

Wrong wording on my part. I wanted to say not derailing the main thread of the PR, since they can become quite polluted over time, opening a thread would have been better, but it's fine.