Document that "features should be additive"

[kennytm]

Although it seems to be well-known, I find it surprising that the requirement "features should be additive" is not documented at all on docs.crates.io. Disrespecting this leads to tricky errors when merging features like chyh1990/yaml-rust#44 and rust-bakery/nom#544 (= #4323).

rust-lang/rfcs#1841 mentioned some documentation changes which should better be added here.

[mimoo]

Hey! This is surprising to me as I see a lot of crypto crates that let you choose your backend via mutually exclusive features. Is there any plan to actually enforce this? And what are the issues with mutually exclusive features?

[sfackler]

How would that be enforced?

Cargo takes the union of all features that are enabled for a crate throughout the dependency graph. If two crates end up enabling two mutually exclusive features of another crate, then they'll both be enabled when building it. The result of that would depend on the implementation of the crate.

[mimoo]

An easy way would be to actually build the crate with --all-features and notice that it fails, but I can see how that would be too much overhead :)

It doesn't seem to be a problem only for mutually exclusive crates.

For example imagine that:

• you have crate A and B in your workspace
• hey both call crate C which verifies signatures of some critical payload unless used with feature flag "no_verify"
• crate A actually needs to skip verification, while crate B doesn't
• do we end up with both crates skipping verification?

(you can imagine the verification being skipped with if cfg!(feature = "no_verify") which seems like it was created for exactly this kind of usecases)