Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #119930 - Urgau:check-cfg-empty-values-means-empty, r=p…
…etrochenkov Add way to express that no values are expected with check-cfg This PR adds way to express no-values (no values expected) with `--check-cfg` by making empty `values()` no longer mean `values(none())` (internal: `&[None]`) and now be an empty list (internal: `&[]`). ### Context Currently `--check-cfg` has a way to express that _any value is expected_ with `values(any())`, but has no way to do the inverse and say that _no value is expected_. This would be particularly useful for build systems that control a config name and it's values as they could always declare a config name as expected and if in the current state they have values pass them and if not pass an empty list. To give a more concrete example, Cargo `--check-cfg` currently needs to generate: - `--check-cfg=cfg(feature, values(...))` for the case with declared features - and `--check-cfg=cfg()` for the case without any features declared This means that when there are no features declared, users will get an `unexpected config name` but from the point of view of Cargo the config name `feature` is expected, it's just that for now there aren't any values for it. See [Cargo `check_cfg_args` function](https://github.com/rust-lang/cargo/blob/92395d90106b3b61bcb68bcf2069052c93771764/src/cargo/core/compiler/mod.rs#L1263-L1281) for more details. ### De-specializing *empty* `values()` To solve this issue I propose that we "de-specialize" empty `values()` to no longer mean `values(none())` but to actually mean empty set/list. This is one of the last source of confusion for my-self and others with the `--check-cfg` syntax. > The confusing part here is that an empty `values()` currently means the same as `values(none())`, i.e. an expected list of values with the _none_ variant (as in `#[cfg(name)]` where the value is none) instead of meaning an empty set. Before the new `cfg()` syntax, defining the _none_ variant was only possible under certain circumstances, so in rust-lang/rust#111068 I decided to make `values()` to mean the _none_ variant, but it is no longer necessary since rust-lang/rust#119473 which introduced the `none()` syntax. A simplified representation of the proposed "de-specialization" would be: | Syntax | List/set of expected values | |-----------------------------------------|-----------------------------| | `cfg(name)`/`cfg(name, values(none()))` | `&[None]` | | `cfg(name, values())` | `&[]` | Note that I have my-self made the mistake of using an empty `values()` as meaning empty set, see rust-lang/cargo#13011. `@rustbot` label +F-check-cfg r? `@petrochenkov` cc `@epage`
- Loading branch information