-Z build-std with unified workspace

[Ericson2314]

If I'm not misreading the Cargo code:

• We currently have separate workspace for the user's project std
• We resolve them separately and then combine the unit graphs

I don't think this is a good approach, long term:

• It's very unlike the rest of Cargo, and exercising a bunch of cases that wouldn't be otherwise possible. This is a recipe for bugs.
• When user crate features effect std features (Build the standard library with different cargo features #4 + Explicit standard library dependencies cargo#5002), resolution is necessarily intertwined.

Conversely, we might inject the crates and (explicit and implicit) stdlib deps to create a unified workspace. We would also combine the lock files to create a lockfile for the combined workspace with the materialized. Now, this will be a bunch of work up front, but I think it comes with a bunch of benefits:

• It's not adding expressive power: one could also manually combine the workspace, lockfile, and add the stdlib deps and then run Cargo on it. This means no new code paths downstream of the workspace combination.
• Since everything is resolved at once, std features affected by project crate features

I also wonder if it might help with #23 (comment). Combining the workspaces and lockfiles is also a "big global change", so maybe it's OK to use source for mirroring just in that case?

[lygstate]

What's the plan to stablize -Z build-std?

[Ericson2314]

Hopefully not until these changes are done...

[adamgemmell]

This was discussed at length on Zulip. The crux of the issue is that because the standard library's crates.io dependencies can use nightly features (often hidden behind a Cargo feature flag), their versions cannot be changed. Currently the Cargo resolver does not allow conflicting versions of a dependency (different semvers with the same major version) in the same resolve - meaning any shared dependencies would have to be locked to the standard library's version.

The general reason for this restriction is that types defined in different versions of the same dependency are considered different types and are not interchangeable. However, the standard library does not actually leak types defined in its dependencies and all types in its API are its own. This means this restriction could be lifted somewhat for std's dependencies. std's dependencies could be classed as Private Dependencies which seems like the best way to make these resolve changes more generalised.