Resolve dependencies based on feasible target/target_os platform combinations

[oscargus]

Problem

There are a few related issues to this: #5896 is maybe the closest.

Concrete example:

I want to use the webbrowser crate.

webbrowser depends on jni for target_os = android
https://github.com/amodm/webbrowser-rs/blob/eff4ccbfd373e88df5dbfd6337eabd69b60b08be/Cargo.toml#L34-L35

The latest released jni depends on windows-sys for target = windows

https://github.com/jni-rs/jni-rs/blob/c79df460a2ca06984e35f67be8ddc13dfab542a7/Cargo.toml#L37-L38

Independent of build target this version of windows-sys will never be used.

Proposed Solution

Have the resolver figure out that windows-sys 0.45 will never be a dependency of webbrowser and therefore not of my project.

Notes

Now, I realize that one says target_os and the other is just the general "windows", so maybe it depends on that. But if the resolution could take these things into account (which I do not think it does, even if it using target_os = "windows", but correct me if I am wrong), that will help de-bloating Cargo.lock.

[epage]

I can very much understand the need for this. There is also #7058 which asks for including the minimum set of dependencies needed for any supported set of --target values which is slightly different than #5896 which sounds like its focused on a specific invocation. Depending on the approach, that issue could be a superset of this issue. You can find a summary of our team discussion on that in https://blog.rust-lang.org/inside-rust/2025/02/27/this-development-cycle-in-cargo-1.86/#specifying-supported-platforms-in-packages

In those notes, it mentions that tracking the path to a dependency to know which cfgs are relevant can get quite tricky. On top of that, doing the cfg set logic between the different target tables could end up being very brittle and difficult for us to maintain the expectations that changing the version of cargo should not change your Cargo.lock.