Today the --filter-platform flag to the cargo metadata subcommand defaults to $CARGO_BUILD_TARGET or the configuration of build.target within .cargo/config.toml. This behavior does not appear to be overridable (or I'm also perhaps missing something in which case this issue is moot), meaning that if a tool wants to execute cargo metadata specifically without a platform filter then there's no way for the tool to opt-in to that behavior.
This issue is downstream of mozilla/cargo-vet#652 where the bug doesn't actually lie in that repository, but rather in the interaction of the various features in play here. In short cargo vet runs cargo metadata to learn about the crate graph and generally wants all information about all platforms. Locally I have build.target configured in .cargo/config.toml, however, which means that the results of cargo vet are subtly different on my machine. This discrepancy in behavior was the source of the original bug report.
To reproduce this behavior while I'm sure it can be minimized further I can see this with the wasmtime repository:
$ cargo metadata --format-version 1 | shasum
8272634713a68939780da2c8387b5ddcab57dbc7 -
$ cargo metadata --format-version 1 --filter-platform x86_64-unknown-linux-gnu | shasum
4525e3f757ea995e4691188f26b4fc44f7ef6379 -
$ CARGO_BUILD_TARGET=x86_64-unknown-linux-gnu cargo metadata --format-version 1 | shasum
4525e3f757ea995e4691188f26b4fc44f7ef6379 -
Effectively --filter-platform, as expected, changes the output of cargo metadata. The CARGO_BUILD_TARGET then affects this by default so even when --filter-platform isn't passed it produces the same output as-if it were passed.
I'll note that I'm assuming that the behavior of reading CARGO_BUILD_TARGET is intentional, but I also realize that may also not be intentional. If it's not intentional, then that's also a possible fix to this! If it is intentional, then this would boil down to a feature request to have a CLI flag for something like --filter-platform all to explicitly request, regardless of other configuration, that no filter be applied.
Today the
--filter-platformflag to thecargo metadatasubcommand defaults to$CARGO_BUILD_TARGETor the configuration ofbuild.targetwithin.cargo/config.toml. This behavior does not appear to be overridable (or I'm also perhaps missing something in which case this issue is moot), meaning that if a tool wants to executecargo metadataspecifically without a platform filter then there's no way for the tool to opt-in to that behavior.This issue is downstream of mozilla/cargo-vet#652 where the bug doesn't actually lie in that repository, but rather in the interaction of the various features in play here. In short
cargo vetrunscargo metadatato learn about the crate graph and generally wants all information about all platforms. Locally I havebuild.targetconfigured in.cargo/config.toml, however, which means that the results ofcargo vetare subtly different on my machine. This discrepancy in behavior was the source of the original bug report.To reproduce this behavior while I'm sure it can be minimized further I can see this with the wasmtime repository:
Effectively
--filter-platform, as expected, changes the output ofcargo metadata. TheCARGO_BUILD_TARGETthen affects this by default so even when--filter-platformisn't passed it produces the same output as-if it were passed.I'll note that I'm assuming that the behavior of reading
CARGO_BUILD_TARGETis intentional, but I also realize that may also not be intentional. If it's not intentional, then that's also a possible fix to this! If it is intentional, then this would boil down to a feature request to have a CLI flag for something like--filter-platform allto explicitly request, regardless of other configuration, that no filter be applied.