Add cargo {test,doc,...} --all-features

[tomaka]

When running tests on travis, you usually want to enable all the features when running cargo test. However this requires manually passing all non-default-features one-by-one. It is easy to forget one.

An option should be added to enable all the features.

The follow-up should be to submit a PR or open an issue to travis so that its engine runs cargo test --verbose --all-features instead of just cargo test --verbose by default.

[SimonSapin]

I’d also like cargo test without argument to default to testing with a multiple sets of features specified in Cargo.toml. Currently I have a Makefile to test both with and without a feature, but I never remember to actually use it locally. (Travis-CI uses it, though.)

test:
    cargo test --features query_encoding
    cargo test

[shepmaster]

An option should be added to enable all the features.

Hmm. What about combinations of features? for example

[features]
a = []
b = []

Would there be 3 runs:

1. --features ""
2. --features "a"
3. --features "b"

Or also a fourth?

1. --features "a b"

[alexcrichton]

I'd personally expect this to just pass --features "a b" in that case, re-running all the tests may be a bit much.

[SimonSapin]

Since Cargo doesn’t know how features interact with each other, I think this should be left to the library author. The default would be a single run with no features enabled (unless given on the command line), but Cargo.toml could specify multiple runs, and for each of them the set of features to enable.

[lib]
test_features = [[], ["query_encoding"]]

[lib]
test_features = [[], ["a"], ["b"], ["a", "b"]]

[esclear]

I'm currently working on implementing support for a basic --all-features flag.
The scope of my approach to it (just enabling all flags for the project / crate) is not with @SimonSapin's proposal, which might also involve #2980.

I personally would prefer doing what seems most intuitive, just enabling all features.
Having specific feature sets could be nice as well, but I think that this flag would be most useful for building documentation or installing certain binaries.
Testing is obviously another possible use case, but I don't think that a test (as part of a feature) that requires another feature being disabled is not that feasible.

[esclear]

Implemented in #3038, but without special feature sets for testing.