Detect invalid cfg expressions, such as the cfg(feature_s_ = ...) typo

[p-avital]

What it does

It's generally easy to mistakenly use features = "x" instead of feature = "x" in cfgs.

To my knowledge, features = "x" doesn't currently have meaning, so it's likely to be the result of a mistake, and not intentional.

The main thing to look out for when looking for this pattern is to ensure that we're within a cfg context.

This can be generalized to ensuring that cfg conditions are always looking at "variables" that actually exist, such as target_family, target_os, etc...

Lint Name

invalid-cfg-condition

Category

correctness, suspicious

Advantage

• Prevent accidental typos that fundamentally alter the behaviour

Drawbacks

• If/when new "variables" are added to cfg conditions, the lint will need to be updated.

Example

#[cfg(features = "std")]
pub use std::error::Error;

const fn std_support_enabled() -> bool { cfg!(features = "std") }

Is highly likely to be an attempt at writing:

#[cfg(feature = "std")]
pub use std::error::Error;

const fn std_support_enabled() -> bool { cfg!(feature = "std") }

[taiki-e]

FYI, rustc/cargo have an unstable option for this:

• Tracking Issue for RFC 3013: Checking conditional compilation at compile time rust#82450
• Tracking Issue for rustc --check-cfg integration cargo#10554

[epage]

FYI the cargo/rustc feature has been proposed for merge. Cargo has approved its side of it and its waiting on rustc.

See also #11649

[Alexendoo]

Closing in favour of rust-lang/rust#82450