Mark existing well-known cfg as unknown

[Urgau]

There is no way to mark existing well-known attributes as unknown, is there? Specifically, I think it would be nice if there was a way for rustc to raise a warning when it encounters cfg(test) (which cargo could then make use of for crates that use lib.test = false).

Originally posted by @jplatte in #82450 (comment)

@rustbot label +C-discussion +F-check-cfg -needs-triage

[Urgau]

This is an interesting idea and as currently noted there is no mechanism to mark an existing cfg as "unknown".

I didn't knew one could set lib.test = false. I could see use introducing a syntax to do that but I wonder in which capacity it would be useful. Would you happen to know other cases where it might be useful?

[jplatte]

It can be useful to set lib.test if you don't actually want to have unit tests on some or all crates in a workspace (instead relying on doctests and/or integration tests, both of which that flag doesn't impact), because by default, all crates will be compiled an extra time with cfg(test) and the test harness, and when there are no tests you'll get "running 0 tests" as well as some other pointless command-line output, which can make finding actually relevant output harder.

There is also a Cargo issue somewhere about improving this output, but even without that, it would be nice if lib.test = false was less "dangerous". Right now it is somewhat easy to miss this flag being set when writing unit tests. I'm pretty sure rust-analyzer will still provide autocomplete in the never-enabled test module and such (I guess I should also report this as a bug), and running the entire test suite at once will still work, just not include the new tests.

If check-cfg would alert people of unit tests not being wanted in certain crates, that would make me more likely to use lib.test = false in a few cases where there's no internal API to be tested and integration tests are preferable.

[jplatte]

Ah, I just checked rust-analyzer's behavior in detail and got reminded that lib.test = false just disables tests by default. They can still be run with cargo test --lib. Maybe marking cfgs as unknown could still be useful for crates that want no unit tests, but then it would be opt-in instead of automatically applied through Cargo I guess. Something like

println!("cargo:rustc-check-cfg=cfg(not(test))"); // or
println!("cargo:rustc-check-cfg-not=cfg(test)");

in build.rs, maybe.

[Urgau]

I was more referring to the "usefulness" of the syntax where the only known user would have been Cargo test/doctest = false.

As for the syntax it-self I could see us introducing something like unset(name1, ..., nameN).
We could even rename the current cfg(...) to set(...) for which the repetition in --check-cfg=cfg(...) is annoying.

Ah, I just checked [..] and got reminded that lib.test = false just disables tests by default

Hum. This reduce the usefulness to basically zero as marking test as unknown would be wrong, as check-cfg consider setting a cfg but not it's check-cfg equivalent is a missing check-cfg.

[jplatte]

This reduce the usefulness to basically zero as marking test as unknown would be wrong.

Hm, maybe. I guess it depends on what the intention of lib.test = false is. I think the vast majority of projects that set it don't have unit tests at all, and if any were to be introduced, getting a warning would be valuable (whether it results in the test author removing the flag or moving the test code into unit tests). I wonder if there are any projects that use lib.test = false while having unit tests, intentionally.

edit: Have opened a forum post about this: https://users.rust-lang.org/t/cargo-what-is-the-purpose-of-lib-test-false/102361