Fix --check-cfg invocations with zero features

[Urgau]

When generating the --check-cfg arguments for -Zcheck-cfg we currently generate cfg(feature, values()) when there is 0 features. This is wrong since a empty values() would mean that it's possible to have #[cfg(feature)] without a feature name which is impossible.

We replace this by a simple cfg() to still enable well known names and values.

---

Note that currently rustc defines feature as a well known name with ANY values if it's not overridden by Cargo. I plan on submitting a PR to rustc to remove feature from being a well known name so that Cargo is the only source of truth.

This doesn't block this PR from being merged

[rustbot]

r? @ehuss

(rustbot has picked a reviewer for you, use r? to override)

[weihanglo]

Sounds pretty reasonable to me. Thank you!

[weihanglo]

@bors r+

[bors]

📌 Commit 4781592 has been approved by weihanglo

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4781592 with merge 79acbdb...

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 79acbdb to master...

[epage]

When generating the --check-cfg arguments for -Zcheck-cfg we currently generate cfg(feature, values()) when there is 0 features. This is wrong since a empty values() would mean that it's possible to have #[cfg(feature)] without a feature name which is impossible.

To me, this reads as a bug in the design of the syntax if values() is special cased like this while the semantics are different.

[Urgau]

values() (without any specified values) isn't special cased. It means no values are expected.
values("foo", "bar") means that the values "foo" and "bar" are expected.

The issue here lies before that, cfg(feature, values()) means: a config named "feature" exists and takes no values; but this isn't what we want, we want that no config named "feature" with whatever values exists, which is simply achieved by not defining "feature" in the first place.

[epage]

values() (without any specified values) isn't special cased. It means no values are expected.
values("foo", "bar") means that the values "foo" and "bar" are expected.

To put this in Rust types, does values() make it a unit type or an empty array?

struct EmptyValues;
const EMPTY_VALUES = [];

If its like a unit type, then that does feel like special casing.

The issue here lies before that, cfg(feature, values()) means: a config named "feature" exists and takes no values; but this isn't what we want, we want that no config named "feature" with whatever values exists, which is simply achieved by not defining "feature" in the first place.

Is that what we want?

Whether there even is a way to define a cfg as an empty array, I suspect being able to do so for features would offer the best usability.

As a user, if I get an diagnostic saying that features doesn't exist, I assume I fundamentally didn't understand how this worked. However, if I get a diagnostic saying that "foo" doesn't exist for features, then that is much clearer what the next steps are.

[Urgau]

To put this in Rust types, does values() make it a unit type or an empty array?

struct EmptyValues;
const EMPTY_VALUES = [];

If its like a unit type, then that does feel like special casing.

It's more like const EMPTY_VALUES = [];.

Internally it would be more like const EMPTY_VALUES = [None]; where None represent the absence of value since we need to differentiate from "" (empty string).
This follows what is done for --cfg:

• --cfg foo => ("foo", None)
• --cfg foo="" => ("foo", Some(""))

The issue here lies before that, cfg(feature, values()) means: a config named "feature" exists and takes no values; but this isn't what we want, we want that no config named "feature" with whatever values exists, which is simply achieved by not defining "feature" in the first place.

Is that what we want?

I think so, from the perceptive of --check-cfg when config is not to be ever expected, since cargo will never pass --cfg feature=... to rustc, we should not declare feature as expected.

Whether there even is a way to define a cfg as an empty array, I suspect being able to do so for features would offer the best usability.

Being able to say: declare a config as expected with all values as unexpected, is not something that is currently possible.

As a user, if I get an diagnostic saying that features doesn't exist, I assume I fundamentally didn't understand how this worked. However, if I get a diagnostic saying that "foo" doesn't exist for features, then that is much clearer what the next steps are.

I agree, but feature is really unexpected here, making it awkward to say it exist but really no it doesn't.

Saying that feature is unexpected is not wrong but is not 100% true either, same for saying that feature is expected, it is not 100% right but it's not 100% wrong either.

I don't know how to fundamentally improve the situation here.

In rust-lang/rust#118071 I propose to add a diagnostic for this case: = help: consider defining some features in Cargo.toml, which should help, but it's not incredible.

[epage]

imo the right answer, from the users perspective, is for us to say that a cfg can exist but no values are defined.

However. since rust-lang/rust#118071 at least provided some help to the user, that is likely sufficient so long as the design allows us to reconsider this in the future.

[epage]

I've noted this in #10554 for us to discuss during stabillization