Is there a way to enforce correct spelling of features?

Question

Let's assume I have the following feature defined in Cargo.toml:

[features]
my_feature = []

And the following code lives in src/lib.rs:

#[cfg(feature = "my_feature")]
fn f() { /* ... */ }

#[cfg(not(feature = "my_faeture"))] // <-- Mind the typo!
fn f() { /* ... */ }

How can I enforce, that the feature-strings are matched against the list of both explicitly defined and implicitly available features in Cargo.toml so that for instance typos could be avoided?

Herbarium

Something Clippy ought to have a lint for, but apparently doesn't. – Nuncupative

I strongly believe this should be the responsibility of rustc. For instance you could pass down a set of features that you wish the compiler to enforce, instead of pushing this responsibility further to a linter, which is very much optional to use. – Herbarium

rustc doesn't know anything about Cargo.toml. The set of features defined there (and then selected for a compilation) are simply turned into --cfg arguments to the rustc invocation: rustc won't know about any that exist but aren't enabled, nor is Cargo's use of feature as a cfg key in any way special to rustc. – Nuncupative

Exactly, that's why cargo would pass down the flags to rustc if it would be able to take in feature flags for strict checking. – Herbarium

It really seems to me that this is a peculiarity of the build tool, not of rustc per se. A different build tool might use option as a cfg identifier instead of feature; might give each such feature its own cfg identifier each with a boolean value (to indicate whether or not it's enabled); or indeed might do something completely different. Requiring the compiler to offer a validator for the whims of each possible build tool seems unnecessarily complex, and anything else would be coupling it a little too tightly to one particular approach? – Nuncupative

Since Cargo cannot do much on its own, I think the right approach would be for the compiler to either optionally take features which needs to be strictly checked, or would offer a flag to turn this check on for all the already passed down features. I don't think this approach would introduce strong-coupling with a specific wrapper: the word feature is used by core's cfg. – Herbarium

Either way, I'm not sure how this thread actually helps my question. I'm quite happy to continue this discussion here: chat.stackoverflow.com/rooms/62927/rust – Herbarium

Answer 1

When RFC 3013, "Checking conditional compilation at compile time", is implemented, there will be warnings for a #[cfg] referring to a feature name that is not declared by Cargo, just as you're asking for. However, the implementation only just got started (Sep 28, 2021).

The means of operation described in the RFC is just as you suggested, ‘cargo would pass down the flags to rustc’.

---

It may be worth noting that this will not check all conditions appearing in the source text; as described in the RFC:

This lint will not be able to detect invalid #[cfg] tests that are within modules that are not compiled, presumably because an ancestor mod is disabled.

So, it will not confirm that all #[cfg(feature)] are valid on a single cargo check — you will need to test with your various features or combinations of features. But those are the same combinations that you would need anyway to check for compile errors in all of the regular source code that could be enabled; once you do that, the lint will assure you that you don't have any #[cfg(feature)] that are never enabled due to a typo.

Quorum