Remove implicit names and values from --cfg in --check-cfg

[Urgau]

This PR remove the implicit names and values from --cfg in --check-cfg because the behavior is quite surprising but also because it's really easy to inadvertently really on the implicitness and when the --cfg is not set anymore to have an unexpected warning from an unexpected condition that pass with the implicitness.

This change in behavior will also enable us to warn when an unexpected --cfg is passed, ex: the user wrote --cfg=unstabl instead of --cfg=unstable. The implementation of the warning will be done in a follow-up PR.

cc @petrochenkov

[rust-highfive]

r? @JohnTitor

(rust-highfive has picked a reviewer for you, use r? to override)

[est31]

I'm not a fan of this, even though it would have found the bug of #98147 way earlier. I think it's not worth the cost paid in longer command invocations. Also, when you type --cfg=unstabl, what prevents you from typing that for the check cfg too?

[JohnTitor]

This is more of a t-compiler PR than docs one, so r? @petrochenkov

[Urgau]

I'm not a fan of this, even though it would have found the bug of #98147 way earlier. I think it's not worth the cost paid in longer command invocations.

I don't think the cost of having longer CLI args is problematic because:

• cargo starting from this PR Retry command invocation with argfile cargo#10546 now automatically retry with argument file if there to much argument than the platform support
• the benefits are important especially the cost of people struggling, they would immediately see a/the problem

Also, when you type --cfg=unstabl, what prevents you from typing that for the check cfg too?

If it's just cmd args nothing, BUT setting the condition means using the cfg in the code, so having #[cfg(unstable)] in the code would warn because the set and expected are unstabl but the code is waiting on unstable you would then see the problem and would be able to fix it immediately, but with the current implicitness you wouldn't have any warn as unstabl would be expected even thought it it's what you want at all.

[est31]

having #[cfg(unstable)] in the code would warn because the set and expected are unstabl but the code is waiting on unstable you would then see the problem and would be able to fix it immediately, but with the current implicitness you wouldn't have any warn as unstabl would be expected even thought it it's what you want at all.

In the current implementation, if you have #[cfg(unstable)] but set --cfg=unstabl, there will be a warning, it will just complain about #[cfg(unstable)] instead of your --cfg=unstabl. Not optimal but I think it's good enough.

cargo starting from this PR now automatically retry with argument file if there to much argument than the platform support

It's fine that it's technically supported, but I believe that reducing noise in command line arguments should be a goal. Sometimes you do want to run with -v or something and it would be annoying to have even longer command line invocations.

[Urgau]

having #[cfg(unstable)] in the code would warn because the set and expected are unstabl but the code is waiting on unstable you would then see the problem and would be able to fix it immediately, but with the current implicitness you wouldn't have any warn as unstabl would be expected even thought it it's what you want at all.

In the current implementation, if you have #[cfg(unstable)] but set --cfg=unstabl, there will be a warning, it will just complain about #[cfg(unstable)] instead of your --cfg=unstabl. Not optimal but I think it's good enough.

Not if it's coupled with --check-cfg=names(unstable) or --check-cfg=values(unstable)

My main problem with the implicitness is that it's implicit and leads to unexpected problems that we even saw in the rust-lang/rust, that's why I think being more explicit is better and simpler and will lead to better experience for developers. The increase in command line args is unfortunate but it's for the better and that doesn't mean that arguments could not be improved further down.

cargo starting from this PR now automatically retry with argument file if there to much argument than the platform support

It's fine that it's technically supported, but I believe that reducing noise in command line arguments should be a goal. Sometimes you do want to run with -v or something and it would be annoying to have even longer command line invocations.

I don't know if it should be goal but I certainly don't think --check-cfg argument are noise at all.

[petrochenkov]

I think we can try using these stricter rules while the feature is unstable, and even after that.

It will be a backward compatible change to not require --check-cfging names/values already known through --cfg again.
So we can switch back to the current rules if the stricter rules are too annoying.

I'm going to mark this as waiting on team to gather feedback.

[est31]

Going both ways is backwards compatible as per Rust's semver rules, because it's a lint. But yes, breakage is lower one way than going the other way.

[apiraino]

Visiting after T-compiler meeting (see Zulip notes).

The opinion is to tentatively move forward with --check-cfg and test the waters while it's unstable

@rustbot label -I-compiler-nominated

[Urgau]

Based on the previous comment, this is no longer waiting on team, back on the review queue.

@rustbot label -S-waiting-on-team +S-waiting-on-review

[petrochenkov]

Okay, the implementation is trivial so @bors r+

[bors]

📌 Commit ebf4cc3 has been approved by petrochenkov

It is now in the queue for this repository.