Cargo passes a nonexistent feature to `rustc` when building gitoxide

[Shnatsel]

Problem

When running cargo build on https://github.com/Byron/gitoxide Cargo passes a nonexistent feature to rustc: --cfg 'feature="prodash"'. There is no feature prodash in any Cargo.toml, which can be confirmed with rg -t toml prodash.

This breaks cargo auditable which relies on all features passed as --cfg to rustc actually existing in the project. This also breaks builds for some Linux distributions that use cargo auditable, namely Void Linux and NixOS.

When the feature prodash is passed to cargo metadata, the following error is printed:

error: Package `gix-features v0.31.0 (/home/redacted/gitoxide/gix-features)` does not have feature `prodash`. It has an optional dependency with that name, but that dependency uses the "dep:" syntax in the features table, so it does not have an implicit feature with that name.

Steps

git clone https://github.com/Byron/gitoxide
cd gitoxide
git checkout b19a56dcfa9bea86332a84aa4e8fad445e7d1724 # current master
cargo build --verbose

Observe --cfg 'feature="prodash"' appearing in the output even though there is no such feature in any Cargo.toml, which can be confirmed with rg -t toml prodash.

The bug can also be reproduced by running cargo install cargo-auditable; cargo auditable build in the same directory.

I have tried to create a minimal reproducing example that does not rely on the gitoxide repo, but failed.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.70.0 (ec8a8a0ca 2023-04-25)
release: 1.70.0
commit-hash: ec8a8a0cabb0e0cadef58902470f6c7ee7868bdc
commit-date: 2023-04-25
host: x86_64-unknown-linux-gnu
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:OpenSSL/1.1.1t)
os: Linux 7 (horus) [64-bit]

[weihanglo]

prodash is an optional dependency¹, which usually defines an implicit feature under the same name of the dependency². However, if you have a dep:prodash in the features table somewhere, Cargo saw the optional as an implementation detail, so it didn't expose the implicit prodash as a public feature.

Although this is a documented behavior, it is not really ergonomic for 3rd party plugins to interact with Cargo feature resolution. Sorry for the inconvenience. I believe one of the best long-term fix for this is to provide a reasonable lean crate for 3rd party integration, so developers don't need to reimplement stuff Cargo is doing. We are (or I am?) trying to work on it!

Footnotes

1. https://github.com/Byron/gitoxide/blob/b19a56dcfa9bea86332a84aa4e8fad445e7d1724/Cargo.toml#L168 ↩

2. https://doc.rust-lang.org/nightly/cargo/reference/features.html#optional-dependencies ↩

[Shnatsel]

Only passing the public features to rustc via --cfg would fix the issue I'm experiencing.

If the list of cfg's passed to the compiler matched the public features, everything would work fine.

Alternatively, exposing it as a public feature would also resolve the problem.

[weihanglo]

Only passing the public features to rustc via --cfg would fix the issue I'm experiencing.

This would be a breaking change. People may already have #[cfg(feature = "optional-dep")] in source code.

Alternatively, exposing it as a public feature would also resolve the problem.

This would also be a breaking change. People may already have a feature name prodash doing more things not limited to enabling the optional dependency. For example,

[features]
prodash = ["dep:prodash", "additiona-feature-enabled"] # user defined
prodash = ["dep:prodash"] # If Cargo defines this there will be a conflict.

It seems that cargo-auditable assumes --cfg features equals public features. I may try to use
cargo_metadata::Node::features (resolve.nodes.features) or something else to get the correct resolved feature list.

[Shnatsel]

It seems that cargo-auditable assumes --cfg features equals public features.

Yes, it does.

I may try to usecargo_metadata::Node::features (resolve.nodes.features) or something else to get the correct resolved feature list.

This is infeasible due to a chicken-and-egg problem.

cargo auditable runs as a RUSTC_WORKSPACE_WRAPPER to be able to intercept and modify Cargo's rustc arguments. To call cargo metadata I would need to already know the list of public features used in the build. That is what parsing the --cfg 'feature="foo"' arguments is supposed to accomplish.

It might be possible to work around this by calling cargo metadata once more to get the list of all public features and filter the --cfg directives against that list, but then I'd need to be able to reliably locate the correct Cargo.toml based only on the rustc arguments and whatever environment variables Cargo sets for its workspace wrapper. I'm not sure if that's possible, but I'll try.

[ereslibre]

I have tried to create a minimal reproducing example that does not rely on the gitoxide repo, but failed.

Not minimal, but another instance of this issue I think with https://github.com/bytecodealliance/wasmtime.

You can build the toplevel crate normally with:

1. cargo install cargo-auditable
2. cargo auditable build

The issue is reproducible inside crates/c-api. Running cargo auditable build yields:

❯ cargo auditable build
   Compiling wasmtime-c-api v14.0.0 (/home/ereslibre/projects/bytecodealliance/wasmtime/crates/c-api)
thread 'main' panicked at 'cargo metadata failure: error: Package `wasmtime-wasi v14.0.0 (/home/ereslibre/projects/bytecodealliance/wasmtime/crates/wasi)` does not have feature `cap-std`. It has an optional dependency with that name, but that dependency uses the "dep:" syntax in the features table, so it does not have an implicit feature with that name.
', /home/ereslibre/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-auditable-0.6.1/src/collect_audit_data.rs:77:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: could not compile `wasmtime-c-api` (lib)

The workaround that allows us to build the c-api crate is: https://github.com/NixOS/nixpkgs/blob/5148520bfab61f99fd25fb9ff7bfbb50dad3c9db/pkgs/development/interpreters/wasmtime/patches/0001-Use-dep-dependency-due-to-cargo-auditable-limitation.patch