Crate universe: extra crate_features from unrelated crate with resolver = "2"

[ttiurani]

I'm unsure if this is a bug, a missing feature or just a question, but I have a problem with crate universe I can't get around. The background is that tokio has features that can not be built with WASM, but I want to use these features in unrelated non-wasm crates in the same cargo workspace, where I have a WASM crate.

I added a reproduction of this here:

https://github.com/ttiurani/rules_rust/tree/main/examples/crate_universe_failure/extra_crate_features

I'm guessing this problem is not uncommon, and I believe slightly different problem than #1727 (feature unification is not the problem here as the crates are unrelated). Also I am inheriting these tokio features through other upstream crates so don't quite know how I would create separate rust_libraries in my Bazel workspace.

I stumbled across a similar issue with plain Cargo as well, but there using edition = "2021" and/or resolver = "2" fixed the problem:

rust-lang/cargo#11653

Is supporting this behavior of resolver = "2" in the roadmap for crate universe?

[UebelAndre]

I thought this was supposed to be handled by #1710

[UebelAndre]

If I understand correctly, this issue is caused by how crate_universe collects all features from all platforms and applies them to the generated dependencies. In Bazel you compile with the superset of of features because it's not currently possible define a target who's build changes based on the consumer, ignoring any configuration changes in the consumer attribute definitions.

Some possible ideas:

• Make a config_setting for each crate and their features (e.g. tokio_net) and provide a rule to transition these so users can remove features where they don't want them. This feels like it'd explode compile times as if you transition at all Bazel is gonna rebuild all it's dependencies which could then lead to other issues when linking.
• Have crate_universe generate additional targets per feature set in a workspace. Today crate_universe would generate @crate_index_extra_crate_features__tokio-1.32.0//:tokio which contains a combination of all features, but it could also create @crate_index_extra_crate_features__tokio-1.32.0//:tokio, @crate_index_extra_crate_features__tokio-1.32.0//:tokio__rt, and @crate_index_extra_crate_features__tokio-1.32.0//:tokio__rt_net (unsure if the base contains superset of features or bare minimum). This way users could have access to versions of external crates with the desired set of features.

Not sure if anyone else has other ideas. I'm happy to share what I know to help someone find a solution and would be happy to review a pull request 😄

[duarten]

Would a third option be to create a target per target platform, each containing the subset of features enabled for that platform?

[UebelAndre]

I think #2636 might solve this problem but am not sure.