Remove --check-cfg checking of command line --cfg args

[Urgau]

Back in #100574 we added to the unexpected_cfgs lint the checking of --cfg CLI arguments and emitted unexpected names and values for them.

The implementation works as expected, but it's usability in particular when using it in combination with Cargo+RUSTFLAGS as people who set RUSTFLAGS=--cfg=tokio_unstable (or whatever) have unexpected_cfgs warnings on all of their crates is debatable. To fix this issue this PR proposes that we split the CLI argument checking into it's own separate allow-by-default lint: unexpected_cli_cfgs.

This has the advantage of letting people who want CLI warnings have them (although not by default anymore), while still linting on every unexpected cfg name and values in the code.

After some discussion with the Cargo team (Zulip thread) and member of the compiler team (see below), I propose that we follow the suggestion from @epage: never check --cfg arguments, but still reserve us the possibility to do it later.

We would still lint on unexpected cfgs found in the source code no matter the --cfg args passed. This mean reverting #100574 but NOT #99519.

r? @petrochenkov

[petrochenkov]

I don't think this a right thing to do.

Why should a specific lint in rustc compensate for deficiencies in cargo (no RUSTFLAGS or --cfg support targeted at specific crates) or libraries (use of --cfg instead of features despite cargo's poor support for it)?

I think it's fine for people using such a large hammer as RUSTFLAGS=--cfg=tokio_unstable to use -A unexpected_cfgs as well.

[Urgau]

I personally see this as a short/medium term workaround until Cargo fixes the problem on their end.
In particular Pre-RFC: Mutually-excusive, global features would help tremendously.
After Cargo fixes the problem we would change the lint back to warn-by-default.

I think it's fine for people using such a large hammer as RUSTFLAGS=--cfg=tokio_unstable to use -A unexpected_cfgs as well.

Member of the Cargo team have expressed their discomfort and even objection to this.

Why should a specific lint in rustc compensate for deficiencies in cargo?

I agree that from the point of view of rustc it's not great. One possibility could be to make the lint warn-by-default and have Cargo always pass (for now) -Aunexpected_cli_cfgs. Would this remove your concern?

cc @epage (who have strong opinion on this)
@rustbot ready

[weihanglo]

I personally see this as a short/medium term workaround until Cargo fixes the problem on their end.

Could you elaborate why we need this short term workaround when the feature is still in nightly?

[Urgau]

Could you elaborate why we need this short term workaround when the feature is still in nightly?

The feature is currently in nightly but I want to stabilize it in the near future and as far as I know this issue with RUSTFLAGS is the biggest remaining concern.

To be more precise separating in two different lints lets us have warnings for every unexpected cfgs in the code and in the cli, but with the possibility to individually disable one or another without disturbing the other one.

[weihanglo]

See also the discussion on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/check-cfg.20and.20RUSTFLAGS.20interaction

[Urgau]

We (I and members of the Cargo team) had some discussion yesterday about --check-cfg, you find the summary of that discussion (by @epage, thanks) at #82450 (comment).

One proposed solution that was suggested by @epage would be to never check --cfg arguments, in contrast to dividing the check under a different lint (what this PR currently propose), but to still reserve us the possibility to do it later.

This would still mean that we would lint on unexpected cfgs found in the source code no matter the --cfg args passed (ie. reverting #100574 but NOT #99519).

@petrochenkov what do you think about this?

[petrochenkov]

@Urgau @epage
Is RUSTFLAGS still in the environment when rustc is run, or cargo removes it from environment for rustc?
If it is still in the environment we could suppress the warning for all --cfgs found in RUSTFLAGS specifically.

[Urgau]

Is RUSTFLAGS still in the environment when rustc is run, or cargo removes it from environment for rustc?

It is still in the environment, but the rust flags can also be set from the .cargo/config.toml file:

[target.<triple>]
rustflags = ["…", "…"]

and those are not included in the RUSTFLAGS env (when mixed only the env takes priority).

So I don't think that a viable option; that's also ignoring that we would have to parse the RUSTFLAGS env which doesn't seems particularly attractive to me, note to mention that Cargo maps every TOML option to an env which means that CARGO_TARGET_<target>_RUSTFLAGS is the same thing as the config file above, increasing again the things rustc need to know.

@rustbot ready

[petrochenkov]

Then suppressing the warning for all --cfg seems acceptable to me.

[rustbot]

Could not assign reviewer from: petrochenkov.
User(s) petrochenkov are either the PR author, already assigned, or on vacation, and there are no other candidates.
Use r? to specify someone else to assign.

[Urgau]

I've updated the PR to no longer check any --cfg args (basically reverting #100574). This PR should be ready for review.

@rustbot ready

[petrochenkov]

@bors r+

[bors]

📌 Commit a5658e6 has been approved by petrochenkov

It is now in the queue for this repository.