`dep:` syntax causes build failures in rare cases

[jcgruenhage]

https://github.com/Byron/gitoxide doesn't successfully build with cargo-auditable anymore. It fails in

cargo-auditable/cargo-auditable/src/collect_audit_data.rs

Lines 77 to 80 in 9fa7fb3

	panic!(
	"cargo metadata failure: {}",
	String::from_utf8_lossy(&output.stderr)
	);

. I'm not sure if gitoxide or cargo-auditable is to blame here, and the error message isn't all that helpful to me either:

thread 'main' panicked at 'cargo metadata failure: error: Package `gix-features v0.31.0 (/home/jcgruenhage/dev/github.com/Byron/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.
', cargo-auditable/src/collect_audit_data.rs:77:9

That reads to me as if something tried to enable a prodash feature on gix-features, but I couldn't find such a thing.

For context, afaict, v0.23.0 is the last version that builds. Anything newer than that runs into the above issue. I ran into this while trying to update the version of gitoxide we ship on Void Linux.

[Shnatsel]

The error originates in cargo metadata command that is part of the official Cargo distribution, and that cargo auditable runs to get information about the crates.

I can reproduce the issue on the latest version of the repo from git and Rust 1.70. I will investigate further. Thank you for the report!

[jcgruenhage]

Thanks for looking into this, reporting it is the least I can do when seeing something like this ;)

[Shnatsel]

It seems to be a bug in cargo. It passes --cfg 'feature="prodash"' to rustc even though there is no such feature in the crate, only a dep: declaration. Then, when cargo auditable extracts the list of features passed to rustc and feeds it back to cargo, cargo itself reports an error because the feature it passed to rustc doesn't actually exist.

Unfortunately this is something that will have to be fixed in Cargo, so I cannot provide an ETA for the fix. I will make a minimal reproducing example and submit the issue upstream.

[Shnatsel]

I've filed an issue upstream: rust-lang/cargo#12336

But the turnaround on Cargo issues is not very quick, so I might have to work around this somehow - perhaps with another call to cargo metadata to get the list of actually existing features, and filter the --cfg 'feature=foo' directives against that? That will slow down the build but at least it will work.

[alexandrevicenzi]

I have the same issue building Wasmtime.

The conflict seems to be related to rust-lang/cargo#10788.

The build succeeds without cargo-auditable.

Are there any workarounds for this issue that do not include disabling cargo-auditable?

[alexandrevicenzi]

I found a workaround that seems to work.

Patched Wasmtime.

-wasi = ['wasi-cap-std-sync', 'wasmtime-wasi', 'cap-std', 'wasi-common']
+wasi = ['wasi-cap-std-sync', 'wasmtime-wasi', 'dep:cap-std', 'wasi-common']