Support multiple cargo_metadata feature options

[mciantyre]

The PR follows #78, which did not correct cargo_metadata feature exclusivity. oli-obk/cargo_metadata#118 lets us combine feature options, like --no-default-features --features foo, so we can fix our usage here. As of this PR, the return of cargo_metadata will truly reflect whatever feature options the user passes to cargo-binutils.

The cargo_metadata change was published in 0.10.1, but this PR bumps to 0.11, which is backwards compatible with 0.10.

[rust-highfive]

r? @therealprof

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

[therealprof]

Looks good to me in general. I do wonder whether features and all-features should be mutually exclusive though? Or are they not because all-features only concern the crate in hand while features allows setting any features in the global feature-set?

[mciantyre]

The behaviors of cargo build and cargo metadata are that --all-features invalidates all other --features usage, no matter if --features activates the crate at hand's feature, or a feature from the global set. --all-features also invalidates --no-default-features. The behavior seems to follow

// 1
if matches.is_present("all-features") {
    metadata_command.features(CargoOpt::AllFeatures);
} else {
    if matches.is_present("no-default-features") {
        metadata_command.features(CargoOpt::NoDefaultFeatures);
    }
    if let Some(features) = matches.values_of("features") {
        metadata_command.features(CargoOpt::SomeFeatures(
            features.map(|s| s.to_owned()).collect(),
        ));
    }
}

which means that --all-features is mutually exclusive from the other two options.

But, it's nonetheless valid for me to pass in all three feature options to build, metadata, or a binutil tool:

# 2
cargo metadata --no-default-features --features foo --features my-dep/dep-feat --all-features

I suppose it doesn't matter if the checks in this crate are mutually exclusive, so long as they represent (1). I can update the PR to (1) if you'd like.

As of this writing, the PR assumes that the cargo_metadata crate behaves like the cargo metadata tool, accepting the variety of feature options shown in (2). Snippet (1) might distrust cargo_metadata, implying that we know better about how to combine feature options. I'm leaning towards mimicking what the cargo metadata reference implementation supports, and what we expect cargo_metadata to also support.

[therealprof]

Thanks for the explanation. LGTM then.

bors r+

[bors]

Build succeeded:

• continuous-integration/travis-ci/push