implement package feature unification

[mladedav]

What does this PR try to resolve?

Implements another part of feature unification (#14774, rfc). The workspace option was implemented in #15157, this adds the package option.

How to test and review this PR?

The important change is changing WorkspaceResolve so it can contain multiple ResolvedFeatures. Along with that, it also needs to know which specs those features are resolved for. This was used in several other places:

• cargo fix --edition (from 2018 to 2021) - I think it should be ok to disallow using cargo fix --edition when someone already uses this feature.
• building std - it should be safe to assume std is not using this feature so I just unwrap there. I'm not sure if some attempt to later feature unification would be better.
• cargo tree - I just use the first feature set. This is definitely not ideal, but I'm not entirely sure what's the correct solution here. Printing multiple trees? Disallowing this, forcing users to select only one package?

Based on comments in #15157 I've added tests first with selected feature unification and then changed that after implementation. I'm not sure if that's how you expect the tests to be added first, if not, I can change the history.

I've expanded the test checking that this is ignored for cargo install although it should work the same way even if it is not ignored (selected and package are the same thing when just one package is selected).

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

Would be good to have a cargo tree test as well

[epage]

and cargo fix

[mladedav]

I've added a cargo tree test, I'll just have to fixup history so that it's added before the feature.

That said, I think it might need a bit of design work because using package and selected feature unification has almost identical outuput, but in the former each tree should be taken on its own while in the latter the user should be aware that the features are unified.

For example in one simplified case where a depends on common/a and b depends on common/b; package outputs:

common v0.1.0 ([ROOT]/foo/common)
a v0.1.0 ([ROOT]/foo/a)
└── common feature "a"
    └── common v0.1.0 ([ROOT]/foo/common)
b v0.1.0 ([ROOT]/foo/b)
└── common feature "b"
    └── common v0.1.0 ([ROOT]/foo/common)

while selected currently outputs:

a v0.1.0 ([ROOT]/foo/a)
└── common feature "a"
    └── common v0.1.0 ([ROOT]/foo/common)

b v0.1.0 ([ROOT]/foo/b)
└── common feature "b"
    └── common v0.1.0 ([ROOT]/foo/common)

common v0.1.0 ([ROOT]/foo/common)

and for completeness, workspace outputs:

a v0.1.0 ([ROOT]/foo/a)
└── common feature "a"
    └── common v0.1.0 ([ROOT]/foo/common)

b v0.1.0 ([ROOT]/foo/b)
└── common feature "b"
    └── common v0.1.0 ([ROOT]/foo/common)

common v0.1.0 ([ROOT]/foo/common)

I'm not sure what would be the ideal behavior here though, we probably don't want to have both features coming out of both packages in selected because people often use this to find out what package turned on a given feature. But I don't think we should keep it as is either. Maybe adding an edge that signifies a feature but somehow marks it as coming from unification elsewhere?

For example something like this?

a v0.1.0 ([ROOT]/foo/a)
└── common feature "a"
    └── common v0.1.0 ([ROOT]/foo/common)
└── common feature "b" (unified)
    └── common v0.1.0 ([ROOT]/foo/common)

b v0.1.0 ([ROOT]/foo/b)
└── common feature "b"
    └── common v0.1.0 ([ROOT]/foo/common)
└── common feature "a" (unified)
    └── common v0.1.0 ([ROOT]/foo/common)

common v0.1.0 ([ROOT]/foo/common)

---

Should there be some kind of proposal for these changes? And in that case should I just fixup history with the current behavior or wait for the outcome of that? Or is it fine to make the changes as part of this PR or a different one but without any larger proposal than just the PR?

[epage]

Should there be some kind of proposal for these changes? And in that case should I just fixup history with the current behavior or wait for the outcome of that? Or is it fine to make the changes as part of this PR or a different one but without any larger proposal than just the PR?

We can clean this up and get it merged and leave it as an Open Question on the tracking issue to have the discussion run independent of this PR

[mladedav]

Ok, tree tests are added now as well as one fix test. I did not know what to test for though so I just took a random fix test from edition 2021 to 2024 since the relevant change should break just a specific upgrade from 2018. If you want to test for something different, let me know.

[epage]

Added a note to the tracking issue

We should have a test specifically for the broken cargo fix --edition case

[epage]

So we're creating independent resolves for each package. I take it we can then leave merging of these graphs to a future possibility to further optimize this?

[mladedav]

Just independent ResolvedFeatures, it seems everything works with just a single targeted_resolve, though I did not expect that since the field is documeted with "The narrowed resolve, with the specific features enabled." Then from those independent unit graphs are constructed and those are then merged into a single build context.

I probably don't understand the whole process well enough, but I don't see a way to merge anything earlier?

[epage]

Maybe phrased differently, if you have the following

a -> common w/ features=foo
b -> common w/ features=foo
c -> common

Will we have 2 or 3 entries in the unit graph?

[epage]

Thanks for moving this forward!

[epage]

Feel free to edit the commits as needed

[mladedav]

I've also just added a test with weak dependencies, which works. I tried to also add namespaced dep: features, but those seem to not be unified (#15694) so I'm ignoring that, but I guess that might also go towards the feature unification's unresolved questions.