cargo metadata: Allow providing cfgs in addition to --filter-platform

[seritools]

Problem

Note: Split off of (and blocks) this rust-analyzer issue: rust-lang/rust-analyzer#19846

cargo metadata has a --filter-platform flag to return the effective dependency tree for a given platform, evaluating conditional dependencies like [target.'cfg(windows)'.dependencies] and culling dependencies that evaluate to false.

This target dependency syntax supports any cfg condition, though:

[target.'cfg(my_custom_cfg = "foobar")'.dependencies]
bar = { workspace = true }

However, there doesn't seem to be a way to provide additional cfgs for cargo metadata's dependency evaluation outside of setting one of the RUSTFLAGS environment variables.
This means that these conditional dependencies will be filtered out (for example by rust-analyzer's call of cargo metadata, see the linked issue above) as soon as --filter-platform is used.

Proposed Solution

From my limited perspective it seems that cargo metadata is missing a parameter like --filter-cfg that would allow specifying these additional cfgs, bringing them to parity with platform-defined cfgs.
The proposed solution would be to add --filter-cfg with effectively the same syntax as rustc's --cfg.

Notes

If this seems reasonable (or another way that might be) I'd like to give implementing it a try. Any guidance here would be appreciated!

[epage]

However, there doesn't seem to be a way to provide additional cfgs for cargo metadata's dependency evaluation outside of setting one of the RUSTFLAGS environment variables.

Is there a reason RUSTFLAGS is insufficient?

In past discussions on cfgs, we felt that they were rustc-specific mechanism and we wouldn't add functionality for them, e.g. #11631 (comment)

[seritools]

Is there a reason RUSTFLAGS is insufficient?

In normal cargo usage, no -- that's exactly where the cfgs would come from, after all.

I think it's mostly an issue in conjunction with rust-analyzer: Rust-analyzer allows rust-analyzer.cargo.cfgs to configure which cfgs should be considered enabled, but this does not propagate through to cargo metadata when querying/discovering the workspace. Yet doing so would clobber existing RUSTFLAGS 😕 🤔

[seritools]

After thinking about it more, yeah, RUSTFLAGS should be sufficient, and it seems like a pretty r-a-specific problem that doesn't necessarily warrant a change on the cargo side.