RFC: Checking conditional compilation at compile time by sivadeilra · Pull Request #3013 · rust-lang/rfcs (original) (raw)

@jyn512 writes:

What happens if the build script forgets to do this (as will be the case for all proc-macros just after this is implemented)? Will cargo still warn about the missing cfg? That doesn't seem ideal.

Nothing will happen, because Cargo will not enable checking the set of all --cfg names, only the set of values specified for feature. Cargo would specify --cfg valid_values(feature, "foo", "bar", ...), but by default would not specify --cfg valid(...).

Or, we could have Cargo change its behavior depending on whether there is a build.rs file or not. If there is no build.rs file, then Cargo could also enable checking cfg names (not just feature values, but cfg names). For crates where a build.rs file is used, we could disable this by default to prevent any breaks. Telemetry (like Crater runs) could then be used to find where this has any negative effect. If it's a reasonably small number of crates, I could work with the crate owners so that they could add the right --cfg valid(...) options to cover their cases. Then, this could be turned on by default, even for crates that have build.rs scripts.

This also doesn't seem to consider that you can set --cfg in arbitrary ways [...]

Good to know; I wasn't aware of docsrs.

I think this just emphasizes that it's good to split this into two parts: the mechanisms (which go in rustc) and the policy (when to use it, and when not to use it). Maybe the best policy to start with (post-stabilization) would be:

  1. The code is present in rustc, but doesn't do anything until you opt-in.
  2. Cargo always specifies valid_values(feature, ...) so that feature values are checked, but nothing else is checked.
  3. A new Cargo.toml property controls whether checking is turned on for a given package (or crate within a package).
  4. We iterate on these use cases (such as building docs, build.rs scripts, etc.) to find where this can be applied.

The goal is to make life better for devs, not worse, of course. :) I think getting the mechanisms into the compiler, and then experimenting with how to turn them on/off, would be a good first step.