feat: implement workspace feature unification

[aliu]

What does this PR try to resolve?

Adds workspace feature unification for #14774

How should we test and review this PR?

In a workspace that has dependencies with different activated features depending on the packages being built, add the resolver.feature-unification = "workspace" option to .cargo/config.toml. Build the entire workspace with --workspace and then build individual packages, ensuring no dependencies are being recompiled.

Additional information

Originally, the RFC and tracking issue mention some more complex changes required in cargo's dependency/feature resolution phases in order to support workspace feature unification. However, it seems like it also works by just modifying the list of PackageIdSpecs passed to the workspace resolver to include all workspace members, and then using the original list of specs when generating the build units. I'm wondering if I missed something because this change feels a bit too simple...

I tested it on a fairly large workspace containing about 100 packages and didn't see any recompilations when building with different sets of packages. I also added an integration test that verifies the correct features are enabled. If there are any other test cases I should include, please let me know and I'll try to add it.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @weihanglo (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[epage]

A couple of high level comments

• This will need to start as unstable. We generally have tests to make sure the feature is correctly gated
• We prefer for PRs to add tests in a commit before the feature, with the tests passing. Then the commit that adds the feature updates the tests to still pass
• We should have tests for any relevant cases from the RFC, e.g. cargo install is called out

[weihanglo]

To add, for cargo install, according to the RFC, the field should not apply the behavior to cargo install.

This field will not apply to cargo install to match the behavior of resolver.incompatible-rust-versions.

[weihanglo]

For adding new unstable configurations, see

• https://doc.crates.io/contrib/process/unstable.html
• https://doc.rust-lang.org/nightly/nightly-rustc/cargo/core/features/index.html

We usually also add an unstable doc whenever we add a new unstable feature. The doc draft has been written in the RFC. Feel free to copy and adjust. If you feel writing doc is too much a burden, let us know we can do it in a follow-up PR.

[aliu]

Thank you @epage and @weihanglo for the quick feedback! This is my first PR to cargo, so apologies if I didn't get some things right regarding the process, etc. I will try to address the comments and push an update today.

[aliu]

@rustbot author

[aliu]

@rustbot review

[weihanglo]

Looks awesome! Thank you for the contribution.

[weihanglo]

@aliu if you want to continue working on #14774, feel free to @rustbot claim it