Merge #78

78: Do not treat feature options as mutually exclusive r=therealprof a=mciantyre

Consider a Rust crate with the following features. The crate enables `"foo"` by default, and it also supports feature `"bar"`:

```toml
[features]
default = ["foo"]
foo = []
bar = []
```

Suppose a user wants to build the crate with *only* the `"bar"` feature. The user uses `--no-default-features` to disable `"foo"`, then adds `"bar"`:

```
cargo build --no-default-features --features bar
```

Utilities like `cargo-objcopy` first build the crate, so we would expect that replacing `build` with `objcopy` would yield the same behavior. However, before this PR, using `objcopy` like

```
cargo objcopy --no-default-features --features bar --verbose
``` 

shows the following verbose output:

```
"path/to/cargo" "build" "--features" "bar" "--message-format=json"
```

We notice that `--no-default-features` is dropped.

<details>
<summary>Reproduce in practice</summary>

I noticed this issue when working with newly-added examples in the [`teensy4-rs` project](https://github.com/mciantyre/teensy4-rs). From the hypothetical above, replace `--feature bar` with `--feature rtic`, and add an `--example` flag:

```
git clone https://github.com/mciantyre/teensy4-rs.git
cd teensy4-rs
git checkout 8cf06cf

cargo objcopy --verbose --example rtic_blink --no-default-features --features rtic -- -O ihex out.hex

"/Users/mciantyre/.rustup/toolchains/stable-x86_64-apple-darwin/bin/cargo" "build" "--example" "rtic_blink" "--features" "rtic" "--message-format=json"
   Compiling teensy4-bsp v0.1.0 (/Users/mciantyre/Projects/teensy4-rs)
error: could not compile `teensy4-bsp`.

To learn more, run the command again with --verbose.
error: Failed to parse crate metadata
```

I've intentionally selected an example that fails to link without also specifying `--no-default-features`. The actual error isn't reported in that output. But, the verbose output shows that we're treating these flags as mutually exclusive, favoring `--features rtic` over `--no-default-features`
</details>

This PR proposes that we do no treat these command-line flags as mutually exclusive. As of this PR, the same usage of `cargo-objcopy` results in the expected `build` command that has both flags.

We seem to also treat these flags as mutually exclusive when constructing the metadata command:

https://github.com/rust-embedded/cargo-binutils/blob/bd59333418dbbe34b8caa9c772745f092ed7832f/src/lib.rs#L279-L287

This PR does not address that usage. It looks like `cargo_metadata` [treats these arguments as mutually exclusive](https://docs.rs/cargo_metadata/0.10.0/src/cargo_metadata/lib.rs.html#451-454), since there's only one `features` value, which is possibly one of three `CargoOpt` variants. Fixing that seems out of scope.

Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com>

Author: bors[bot]

src/lib.rs

@@ -491,9 +491,11 @@ fn cargo_build_args<'a>(matches: &'a ArgMatches<'a>, cargo: &mut Command) -> (Bu
         for feature in features {
             cargo.args(&["--features", feature]);
         }
-    } else if matches.is_present("no-default-features") {
+    }
+    if matches.is_present("no-default-features") {
         cargo.arg("--no-default-features");
-    } else if matches.is_present("all-features") {
+    }
+    if matches.is_present("all-features") {
         cargo.arg("--all-features");
     }