RFC: Give users control over feature unification

[epage]

This adds resolver.feature-unification to .cargo/config.toml to allow workspace unfication (cargo-workspace-hack) or per-package unification (cargo hack).

Rendered

[joshtriplett]

Thank you so much for turning the RustConf discussions into RFC prose so quickly!

[joshtriplett]

I'm going to go ahead and start the asynchronous process of checking for consensus or concerns on this idea. People should feel free to read and consider at their leisure, and we can always discuss it further; just want to give a place for folks who have had a chance to review it to register either consensus or concerns or both.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[RalfJung]

The main situation I encounter this with is a workspace that has a single package, but the different cargo targets have different dependencies and that affects feature resolution in a way that cargo build vs cargo test leads to rebuilds. Will this RFC help there? If yes, then the text should be clarified, because it seems to talk entirely about packages but not about targets within a package. If not -- what would it take to help in that situation?

[epage]

Thanks for calling this out! I had considered this but forgot it and didn't want to hold it up until I could remember.

[epage]

@sunshowers says cargo-hakari will unify normal and dev-dependencies. Platforms are not unified.

[epage]

@sunshowers says that is also unifies the features that workspace member features enable

[epage]

Some cases with unifying dev-dependencies include

• fail being used for dev-dependencies but not production
• Tests enabling std but not wanting them for normal build
• Some use case related to private keys where the impl Clone is only provided on debug builds and not release builds

There are likely other cases of this same sort of problem

[RalfJung]

In Miri's case it's dev-dependencies enabling different features for libc or some other fundamental crate, which means that even after cargo test, doing cargo build does an almost complete re-build of Miri -- that's waiting time I'd rather avoid. :)

[epage]

I've summarized this under "Future possibilities"

[weiznich]

I'm not a team member of any of the relevant teams here at all, but I nevertheless want to raise some concerns. The proposed text is very light on details what should happen regarding feature unification between host and target crates, especially for shared dependencies of them. The last time the cargo team performed changed on how feature unification worked with the 2021 edition they broke existing crates in an incompatible way. (The argumentation for that essentially was: It's required for other use-cases to work, which is really not that great if you part of the number of crates that broke due to this.)
I raised similar concerns back then a bit later in the process. It was ignored back then, so I figured that it might be worth to raise this just in the beginning this time. I would be very grateful if some of the official team members could list this as concern in the FCP comment.

As additional observation: The resolver = "2" feature back then was already forced onto upstream crates, this now introduces another potentially equally breaking feature in another location again controlled by downstream crates. I'm not 100% sure if it's really a good idea to have controls for the resolver behavior in various different places and also I'm still not sure if it's the correct solution to introduce these potential upstream package breaking changes at all.

That written: It would be surely helpful to have some sort of control over how feature unification works, but maybe that should not be done at a workspace level, but rather be up to control of who puts there the actual dependency? That would allow me as a crate author of some inter-dependent crates to correctly control how cargo treats features for these interconnected crates.

[DragonDev1906]

that people will pressure crate maintainers to support this configuration.

Correct me if I'm wrong, but if I understood it correctly enabling this will only have an impact on crates inside your own workspace. Not on any crates that depend on crates in this workspace. Therefore why would people want/need to "pressure crate maintainers" to "support this", if they don't get a benefit from it? They would have to enable it in their own workspace to see a benefit and won't notice any change if their dependency enables it in their workspace.

Unless I'm mistaken Cargo doesn't care if your dependency is in a workspace containing other crates and already does not do feature unification in the workspace of your dependency (all your dependencies are compiled with -p and all features needed in either (a) your entire workspace or (b) all features needed by your package, like if you use -p).

It's not like you can't enable/use this if any of your dependencies doesn't have/use it.

Wouldn't therefore only the developers working in the workspace itself see a benefit from this?

[weiznich]

@DragonDev1906

Correct me if I'm wrong, but if I understood it correctly enabling this will only have an impact on crates inside your own workspace.

That's wrong, this feature will affect all dependencies of your own workspace. So people will (naturally) go to upstream crates and request that this or that works if the build is "suddenly" broken. That is especially an issue if the feature is promoted as something that significantly improves compile times, because then it feels for the workspace author like: I really want to improve my compile times but I cannot because of the upstream crate xyz. That will naturally result in a certain pressure towards to the maintainers of crate xyz.

[hanna-kruppe]

As I understand it, the problem already occurs today when you run a cargo command on the whole workspace, right? That’s not a rare thing to do: with a virtual manifest as workspace root (not the only option, but a common one), it affects pretty much every manual cargo invocation from the root directory without passing -p some-member. It’s also how rust-analyzer likes to work and a common configuration for any cargo check/clippy run by the IDE (you can restrict these cargo commands to the crate currently being edited, but this is often less convenient because you don’t get immediate feedback about errors in other crates than the one you’re editing). I’ve never been in the unfortunate situation of being impacted by this bug, but “never run a whole-workspace command” does not sound like a very practical workaround even today.

In the terms of rust-lang/cargo#14415, it seems to me that an easier workaround is for the user to change their crate(s) so they always depend on “a” with the same set of features both on the host and the target. This is not great but (when applicable) requires less ongoing effort from developers than avoiding whole-workspace invocations every time they interact with cargo.

[weiznich]

I don't have the feeling that anyone even tries to understand what's the underlying problem here.

Yes you can hit the same problem today, as written before that's already a previous breaking change from the cargo team. In my personal opinion they shouldn't really expose more ways to do that until they started working on a fix for that previous regression, but at least @epage already dismissed that. (So much to the stability guarantees…)

To write that again: My main concern is: Currently this is mostly in the line off "Well figure out your workspace crates on your own", but that changes as soon as the team actively promotes this feature as "Enabling this feature will speed up your compile times significantly", which is exactly what this RFC does as main motivation. This communication changes the expectation of users on their dependencies from "Well this won't work for me so I just change something on my side" to "This now slows down my build, you need to fix that". Please understand that this is really not a desirable situation to be in as crate maintainer.

The alternative that I as crate maintainer see is to tell exactly these users to go and yell at the cargo team instead of yelling at me + explicitly document on diesels side that this setting is unsupported from our end due to the potential breakage outlined above. I'm quite sure the cargo team would prefer as well to not have that situation.

Now again, I think that's not hard to address from the RFC author/cargo team. Possibilities are to tweak their communication so that:

• This is not a 100% certain way to improve performance
• This might break things and this breakage is up to the workspace user
• Maybe not promoting this feature as compile time performance motivated at all

And sure, you can all dismiss this, but again I think the rust ecosystem already has a large enough burnout problem, so there is really no need to introduce more reasons to burn out there.

In the terms of rust-lang/cargo#14415, it seems to me that an easier workaround is for the user to change their crate(s) so they always depend on “a” with the same set of features both on the host and the target. This is not great but (when applicable) requires less ongoing effort from developers than avoiding whole-workspace invocations every time they interact with cargo.

That's not desirable as soon as you have native dependencies behind these feature flags.

[epage]

This is not a 100% certain way to improve performance

As I've said before, the RFC does not actually focus on this as a general "build accelerator" feature but as a "keep consistent behavior in scenarios you are already running", see Motivation

This might break things and this breakage is up to the workspace user

See Drawbacks which also re-iterates the performance point above.

[hanna-kruppe]

I don't have the feeling that anyone even tries to understand what's the underlying problem here.

I'm sorry for giving this impression. I should have been much clearer about how my comment relates to what you're saying. Tacking on an afterthought (the second paragraph) which doesn't related to any of your main points didn't help. Let me try to rectify that:

I'm trying to probe to what extent and in which sense the proposed resolver.feature-unification = workspace setting does "make it easier to hit this case". In a workspace susceptible to this bug, there are particular Cargo invocations that don't error today but would error with with the new setting enabled. But what I don't understand and would like to clarify is: are there users who have not encountered a build failure due to this issue, and never will unless they enable the new setting? From what I described in my last comment, this seems unlikely to me: they would have to be exceptionally lucky to never trigger a cargo invocation that does trigger it while working on their code base, because it's not easy (or desirable, in most cases!) to completely avoid whole-workspace cargo invocations. If I'm wrong about this, I'd like to understand why. Otherwise, this suggests that the "easier to hit this case" claim may not be true, at least not in the sense I have understood it so far.

I cannot comment on your other points: I'm in no position to edit the RFC, I'm not on any relevant team, and I don't know the inner lives of your users -- by which I mean, I can't and won't speculate whether/how the presence of resolver.feature-unification or how it's advertised will affect how they react to build failures that they would have experienced either way.

[weiznich]

@hanna-kruppe I've taken a step back end tried to reflect on all arguments given so far. I think there are two points that get mixed up all the time here.

The first point is that I personally still consider the proposed change a breaking change. I've gave an example above that works to build in a certain directory. It wouldn't work anymore if the new setting is set. Now that can be set as explicit argument, but it can also be set "implicitly" by the environment, e.g. by a global environment variable or by a "os level" setting (e.g. in ~/.cargo/config.toml), which means you can "easily" end up in a situation where code that happened to compile does not compile anymore due to that setting.
Now the main argument against considering that a breaking change is that this was broken before, as it failed to build in other locations. My main point is that it now fails to build in new locations.
I agree with you in so far here that users that have such a setup are "aware" of that problem, in so far that they know that for whatever reason they need to execute the check/build command in a certain folder. I wouldn't go as far and claiming that they are aware for the reasons why this happens (feature unification), as most users likely treat this as annoyance. Therefore I believe they won't understand the impact on this setting on their setup.

This brings me to my second more important point. I think we all agree on the point that this might expose the "existing breakage" on more locations. As previously explained I do not see that all users necessarily understand the potential impact of this new feature unification setting, especially in such settings as described above. As long as this would be yet another obscure cargo setting, even that would likely be fine. I personally fear that the cargo team is going to promote this as "Enable this setting and get faster builds" feature, which to be fair might be even true for most setups. But if they do that, it suddenly shifts from being yet another obscure settings that is not used often to something that might be popular (as rain pointed out above, for example). That certainly will lead to pressure on the maintainers of crates that cannot support this for the reasons outlined above. That's why I'm asking for an addition to the RFC that explicitly states that preventing this is the responsibility of the cargo maintainers. I don't even think that this is much of a burden for them, as it's mostly a communication/documentation thing, although ideally they also would emit a message for candidates of such failures that just point to the corresponding documentation. The alternative is to not promote this feature as something that improves performance and turn it into yet another obscure setting, which would be even less work.

I personally see the second point and the proposed resolution as important. I still believe that this might be a breaking change, but I see that others might disagree there and I even agree that this edge-case is probably not worth blocking the whole feature over. At least as long as the second point is addressed in a meaningful way.

[LukeMathWalker]

That's why I'm asking for an addition to the RFC that explicitly states that preventing this is the responsibility of the cargo maintainers. I don't even think that this is much of a burden for them, as it's mostly a communication/documentation thing, although ideally they also would emit a message for candidates of such failures that just point to the corresponding documentation. The alternative is to not promote this feature as something that improves performance and turn it into yet another obscure setting, which would be even less work.

I feel you're attributing too much importance to what the cargo team says or does with respect to the way this feature is promoted and/or documented.
If it ends up improving build times for most setups (as you say and I believe), the community will pick up on it and it'll soon be recommended by most learning resources (books/blogs/tutorials) as such, no matter what the official docs say.

[Freax13]

Correct me if I'm wrong, but if I understood it correctly enabling this will only have an impact on crates inside your own workspace.

That's wrong, this feature will affect all dependencies of your own workspace. So people will (naturally) go to upstream crates and request that this or that works if the build is "suddenly" broken. That is especially an issue if the feature is promoted as something that significantly improves compile times, because then it feels for the workspace author like: I really want to improve my compile times but I cannot because of the upstream crate xyz. That will naturally result in a certain pressure towards to the maintainers of crate xyz.

If I'm reading this RFC correctly, this will only affect feature unification for direct dependencies of packages in the workspace and won't affect the feature sets for indirect dependencies. This means that if a workspace package uses the dependency crate_a in the broken workspace you described above, the dependencies of crate_a will always be built in the same way regardless of the new feature unification setting introduced in this RFC, because the dependencies of crate_a are not direct dependencies of the workspace. As a result, it's unlikely that users will flock the the broken namespace containing crate_a because changing the feature unification settings for a workspace using crate_a won't affect the feature unification settings in the broken workspace.

[weiznich]

I feel you're attributing too much importance to what the cargo team says or does with respect to the way this feature is promoted and/or documented.
If it ends up improving build times for most setups (as you say and I believe), the community will pick up on it and it'll soon be recommended by most learning resources (books/blogs/tutorials) as such, no matter what the official docs say.

It's always easier for maintainers if they can just point to the official documentation and say: It's written there, that's expected behaviour. That official documentation is something the cargo team can clearly provide.

The second suggestion I made was to include this information in the emitted error messages, which would make this information even more prominent for users.

For me that doesn't sounds like something where the cargo team does not have any influence, but quite the opposite: They can provide helpful responses without much effort.

If I'm reading this RFC correctly, this will only affect feature unification for direct dependencies of packages in the workspace and won't affect the feature sets for indirect dependencies. This means that if a workspace package uses the dependency crate_a in the broken workspace you described above, the dependencies of crate_a will always be built in the same way regardless of the new feature unification setting introduced in this RFC, because the dependencies of crate_a are not direct dependencies of the workspace. As a result, it's unlikely that users will flock the the broken namespace containing crate_a because changing the feature unification settings for a workspace using crate_a won't affect the feature unification settings in the broken workspace.

As pointed out that is not correct. As soon as you unify features of direct dependencies you change the compile feature resolution for all dependencies.

[Freax13]

If I'm reading this RFC correctly, this will only affect feature unification for direct dependencies of packages in the workspace and won't affect the feature sets for indirect dependencies. This means that if a workspace package uses the dependency crate_a in the broken workspace you described above, the dependencies of crate_a will always be built in the same way regardless of the new feature unification setting introduced in this RFC, because the dependencies of crate_a are not direct dependencies of the workspace. As a result, it's unlikely that users will flock the the broken namespace containing crate_a because changing the feature unification settings for a workspace using crate_a won't affect the feature unification settings in the broken workspace.

As pointed out that is not correct. As soon as you unify features of direct dependencies you change the compile feature resolution for all dependencies.

Can you provide an example of that? Edit: Just to be sure, you're saying that if the features of direct dependencies are unified this can lead to problems in indirect dependencies if the direct dependencies activate features in those indirect dependencies? How is that different from the user just activating an incompatible set of features in their direct dependencies? This can't be solved by the users asking their dependencies to fix their workspaces though, can it?

[weiznich]

@epage

See Drawbacks which also re-iterates the performance point above.

That's does not even touch any of my concerns. It says the following:

This increases entropy within Cargo and the universe at large.

If someone enables mutually exclusive features in different packages, then workspace unification will fail. Officially, features are supposed to be additive, making mutually exclusive features officially unsupported. Instead, effort should be put towards official mutually exclusive globals.

Some features cannot be enabled in some packages, like a no_std package not wanting std features. These workspaces will not be able to use workspace unification. For now, unifying for the "workspace" is primarily targeted at single-application workspaces. The other config fields can always be used instead.

For the example provided there are no mutually exclusive features. The features in question are additive by all common definitions that I'm aware of. You keep saying that this won't work for mutually exclusive features, but I really do not see how that's even the point of the discussion. Nobody claimed that. So can you please point out where exactly the drawback section talks about the case presented above?

Additionally I do not even see any mention around the potential social pressure there. Do I miss something or do you still claim that this won't be a problem. If the later is the case: On which foundation do you believe you can claim that and dismiss my personal experience with previous similar features?

At this point I have the feeling that you either do not want think about all implications or that you mix up what mutually exclusive features are and what not . Both would be highly concerning for a team member in the cargo team.

---

@Freax13

Can you provide an example of that? Edit: Just to be sure, you're saying that if the features of direct dependencies are unified this can lead to problems in indirect dependencies if the direct dependencies activate features in those indirect dependencies? How is that different from the user just activating an incompatible set of features in their direct dependencies? This can't be solved by the users asking their dependencies to fix their workspaces though, can it?

The critical mode is the workspace unification mode. The RFC is relatively light on details on how this feature unification should actually work. I think the important part is:

The same result can be achieved with cargo check --workspace, but with fewer packages built. Therefore, no fundamentally new "mode" is being introduced.

For me that reads like it will not only unify features for direct dependencies, but for all dependencies of the workspace. It still won't unify features between host and target dependencies, but it will unify them for each of those on it's own. Exactly that behavior is what would be problematic with the example provided above.

[Freax13]

For me that reads like it will not only unify features for direct dependencies, but for all dependencies of the workspace. It still won't unify features between host and target dependencies, but it will unify them for each of those on it's own. Exactly that behavior is what would be problematic with the example provided above.

For me, the RFC section you quoted reads like features will always be unified across the top-level workspace like they would be with --workspace even if only a single package is built (with -p <PACKAGE>) and that features are not unified across the workspaces of dependencies because that's also not the case with --workspace right now. @epage can you clarify which interpretation is correct?

[hanna-kruppe]

This "workspaces of dependencies" concept you're talking about doesn't really exist. Any given crate either is a member of the workspace that the user is working in right now, or it's not. In the most common case where non-workspace-members come from the crates.io index, they're self-contained and the rest of the workspace that it may have been developed in isn't even available. Path and git dependencies presumably may have to refer to their respective workspace Cargo.toml to resolve fields that are inherited from the workspace, but I don't think Cargo pays very much attention to those other workspaces afterwards.

In any case, this has nothing to do with Diesel being affected by rust-lang/cargo#14415. As you can see from the minimal example in #3692 (comment), the relevant feature unification is between two members of the "top-level" workspace depending on diesel with different features and as build vs. normal dependency. If you dig deeper, you'll also see features of transitive dependencies (diesel_derives) being unified, and the way resolver v2 unifies between different kinds of dependencies matters too. But none of these aspects have anything to do with "workspaces of dependencies", it's how the resolver (v2) always works even if none of the involved crates were ever in any workspace. Indeed the initial report in rust-lang/cargo#14415 only involves a single crate with two dependency edges to diesel.

[DragonDev1906]

For me that reads like it will not only unify features for direct dependencies, but for all dependencies of the workspace. It still won't unify features between host and target dependencies, but it will unify them for each of those on it's own. Exactly that behavior is what would be problematic with the example provided above.

For me, the RFC section you quoted reads like features will always be unified across the top-level workspace like they would be with --workspace even if only a single package is built (with -p ) and that features are not unified across the workspaces of dependencies because that's also not the case with --workspace right now. @epage can you clarify which interpretation is correct?

I think you're both right: Regardless of this new setting: Cargo will unify the features of all compilation units (direct and indirect dependencies). The only thing this setting changes is which crates are included in this set of compilation units. To me @Freax13' interpretation sounds more accurate though.

In the case of mutually exclusive features you of course can only use selected and package:

• selected (the default) will work as it did in the past, not breaking anything
• workspace will not work (both features enabled), that is correct. It would also be like modifying all your build scripts/commands by replacing -p ... with --workspace. If I understood you correctly this is the main point of concern, but in my opinion not a breaking change, as it is like adding a new number type with a different behavior, then calling it a breaking change because someones code broke because they used the new type.
• package Most likely this is actually what you want (no leaking of features into other crates in the repository), especially for testing whether you missed some feature you actually need. The main downside to this is of course that it increases compile times.

There also is literally no way a dependency with mutually exclusive features could fix this. You also cannot compile diesel with --all-features for the same reason. Having dependencies with mutually exclusive features and opting into workspace effectively means you're using the tools wrong. This is also explicitly mentioned in the RFC, right below the list of options.

I do not think it's feasible for the error/warning message to contain this information, as there is no "official" way to mark two features as mutually exclusive. But there is still the option to output a compile_error!("using mutually exclusive features, may be caused by resolver.feature-unification = 'workspace'") if mutually exclusive features are used.

The only other way I can see for this would be to either:

• allow dependencies to opt-out of this (but something like --all-features and --workspace would still break it most likely - not ideal, as the dependency isn't the issue.
• add a unify="package" field to the dependencies in Cargo.toml, thus allowing the workspace to select/overwrite this per dependency (not sure if that's worth the extra effort).

Personally I think this is fine as long as workspace doesn't become the default.

[weiznich]

@DragonDev1906 I'm not sure why you bring up mutually exclusive features again. As already written several times before: In the provided example are no mutually exclusive features so at least my concern is not around mutually exclusive features.

You also cannot compile diesel with --all-features for the same reason.

Exactly this is wrong. @epage Claimed that without any providing any evidence. You can compile diesel with --all-features enabled (well at least with a nightly compiler as on of the feature flags enables an unstable feature and with some time as another feature requires quite a bit compilation time). If you don't trust me there, just try it yourself. It's likely quicker to just do something like cargo check -p diesel -F postgres -F sqlite -F mysql to enable only the relevant features for the example above.

So yes your statements are correct for mutually exclusive features, but this discussion is about another build error that occurs without mutually exclusive features.

[weiznich]

@epage Thanks for updating the drawback section, it now reads at least remotely like it covers the presented case.

Would it be possible to get an official response from the cargo team to my concern that crate maintainers could be the target of considerable social pressure due to the need to support the workspace unification variant for promised build speedups although that's not possible due to one of the listed drawback variants?

[Freax13]

Would it be possible to get an official response from the cargo team to my concern that crate maintainers could be the target of considerable social pressure due to the need to support the workspace unification variant for promised build speedups although that's not possible due to one of the listed drawback variants?

Is crate maintainers referring to library maintainers (i.e. dependencies) or binary maintainers (i.e. top-level projects)? If it's about library maintainers, I still don't get how this feature makes the situation worse and how a maintainer would possibly fix this. Can you provide an example of a repo that would be affected and how it could be fixed?

[weiznich]

Is crate maintainers referring to library maintainers (i.e. dependencies) or binary maintainers (i.e. top-level projects)?

It refers to the library/dependency crates.

If it's about library maintainers, I still don't get how this feature makes the situation worse

This RFC describes as motivation for the workspace unification variant that this might speed up builds. My main fear here is that maintainers of a library crate can end up in a situation where some of their users demand to support this specific build mode in their setup, while that's technically not possible. Given how heated discussion around build times can become that might result in considerable pressure to theses maintainers, without giving them a way to solve the underlying problem.

The current situation is I'm so far different that this issue is not seen as something that's related to build times.

To summarise that: It's more a concern around the social impact, rather than a hard technical issue, although this new feature can result in failed builds in additional locations.

and how a maintainer would possibly fix this. Can you provide an example of a repo that would be affected and how it could be fixed?

For a affected repo: See the example provided before

For how to fix it: It's not possible to fix this to my knowledge, which is exactly the point I'm trying to make.
(It's a larger issue in how cargo unifies features across host and target dependencies)

[Freax13]

I think it's worth reiterating out that the workspace feature unification mode behaves exactly like adding --workspace to any cargo command and my guess is that most people run build or check/clippy on their projects with --workspace at least sometimes if not most of the time (or they run build in the root directory of a workspace where --workspace can be left out). rust-analyzer passes --workspace by default. My guess is that if workspace feature unification causes problems and these problems could feasibly be fixed by upstream library maintainers, we would already be seeing issues/PRs being opened for that, but I'm not aware of any instances of this (I could be wrong here). Of course, passing --workspace won't work for some top-level projects, but in those cases, I expect that people will already be aware of how feature unification is breaking their workspace and I expect them to realize what workspace feature unification mode is right for them.

Personally, I'm not worried about workspace feature unification across a top-level project breaking a build. I would be concerned if workspace feature unification across the workspace of a dependency breaks a build, but it seems to me like we are all in agreement that this won't happen, because features are not unified across the workspace of a dependency.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ehuss]

Thanks everyone for the comments!

To track further discussion, subscribe to the tracking issue here: rust-lang/cargo#14774