As far as I can tell, crate_universe doesn't support target-specific feature selection.

E.g. (from https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2)

[dependency.common]
version = "1.0"
features = ["f1"]

[target.'cfg(windows)'.dependencies.common]
version = "1.0"
features = ["f2"]

will lead to crate_universe generating

crate_features = [
    "f1",
    "f2",
]

I think it'd be better if it generated something more like

crate_features = select({
    "@rules_rust//rust/platform:x86_64-pc-windows-msvc": ["f1", "f2"],
    "//conditions:default": ["f1"],
})

This is particularly an issue for wgpu-hal and therefore generally for wgpu which fails with errors like like the following (on Mac):

error: DX12 API enabled on non-Windows OS. If your project is not using resolver="2" in Cargo.toml, it should.
  --> external/crates_vendor__wgpu-hal-0.13.2/src/lib.rs:53:1
   |
53 | compile_error!("DX12 API enabled on non-Windows OS. If your project is not using resolver=\"2\" in Cargo.toml, it should.");
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0433]: failed to resolve: use of undeclared crate or module `winapi`
 --> external/crates_vendor__wgpu-hal-0.13.2/src/auxil/dxgi/conv.rs:1:5
  |
1 | use winapi::shared::dxgiformat;
  |     ^^^^^^ use of undeclared crate or module `winapi`
...

Manually updating the BUILD files generated to have the "right" set of features for the given platform allows it to compile successfully.

Looking a bit at cargo-raze, which handles this reasonably well, it appears they're parsing target-specific feature sets from cargo tree rather than cargo metadata because the former supports resolver = "2" while the latter doesn't.

Would you folks be up for a PR attempting to do a similar thing here?