Misreporting of platform default dependencies?

[dekellum]

Using cargo-tree 0.26.0, I noticed something strange with a project depending on flate2 and its transitive dependencies. Namely the dependency tree includes miniz_oxide_c_api even though the rust_backend feature is not enabled.

The flate2 1.0.9 Cargo.toml appears to make the otherwise non-default miniz_oxide_c_api mandatory on wasm32. But I'm not targeting wasm. See excerpt below. Is that what's confusing cargo-tree?

[dependencies]
miniz-sys = { path = "miniz-sys", version = "0.1.11", optional = true }
miniz_oxide_c_api = { version = "0.2", optional = true, features = ["no_c_export"]}

[target.'cfg(all(target_arch = "wasm32", not(target_os = "emscripten")))'.dependencies]
miniz_oxide_c_api = { version = "0.2", features = ["no_c_export"] }

[features]
default = ["miniz-sys"]
zlib = ["libz-sys"]
rust_backend = ["miniz_oxide_c_api"]

Here is a minimal reproduction test project:

[package]
name = "cargo-tree-opt-dep-test"
version = "0.1.0"
edition = "2018"

[dependencies]
flate2 = "^1.0.9"
brotli = {version = "^3.3.0", optional = true}

[features]
default = []

With the following output from cargo tree:

cargo-tree-opt-dep-test v0.1.0 (/home/david/src/cargo-tree-opt-dep-test)
└── flate2 v1.0.9
    ├── crc32fast v1.2.0
    │   └── cfg-if v0.1.9
    ├── libc v0.2.60
    ├── miniz-sys v0.1.12
    │   └── libc v0.2.60 (*)
    │   [build-dependencies]
    │   └── cc v1.0.38
    └── miniz_oxide_c_api v0.2.3
        ├── crc32fast v1.2.0 (*)
        ├── libc v0.2.60 (*)
        └── miniz_oxide v0.3.0
            └── adler32 v1.0.3
        [build-dependencies]
        └── cc v1.0.38 (*)

Note that the optional brotli dependency isn't shown, so cargo tree does pay attention to features. Here is cargo clean && cargo build output showing miniz_oxide_c_api isn't built:

  Compiling libc v0.2.60
   Compiling cc v1.0.38
   Compiling crc32fast v1.2.0
   Compiling cfg-if v0.1.9
   Compiling miniz-sys v0.1.12
   Compiling flate2 v1.0.9
   Compiling cargo-tree-opt-dep-test v0.1.0 (/home/david/src/cargo-tree-opt-dep-test)
    Finished dev [unoptimized + debuginfo] target(s) in 3.85s

[dekellum]

Also I should mention: I get the exact same dependency tree, if I explicitly specifying my default target via cargo tree --target x86_64-unknown-linux-gnu, which is obviously not wasm32.

[sfackler]

We're probably touching some bit of cargo's internals incorrectly. Luckily, it seems like we're pretty close to cargo metadata having all of the bits of information we need to stop using cargo-the-library entirely which should remove a whole set of issues like this.