Currently sysroot crates have hard-coded dependencies on other sysroot crates, but in reality they can also depend on almost arbitrary crates.io crates, and we currently miss those. This can break stuff, for example
std::os::unix isn't resolved correctly because the module declaration is produced by
cfg_if!. (I'm pretty amazed that the current solution has held up so well!)
I think the correct way to fix this is to start using
cargo metadata output, just like we do for user workspaces. The problem with that is that it means we might perform network requests and block for a while when the index is being updated. I think it also means that cargo will create
Cargo.lock inside the
.rustup toolchain in use, which is not ideal (but required when we only want to pay the startup cost once).
One other thing that came to mind: The rust-src component ships Cargo.lock, so technically no index update like that is necessary. The problem is that it's not located in the right place, and the workspace it was generated for (the whole rust-lang/rust) is not available. We might be able to generate the libstd part of the workspace and reuse the lockfile though, but that means dealing with temp files etc.
Any ideas / Things I'm missing?
https://github.com/rust-lang/rust/pull/76533 would be ideal
Ah yeah, that might help. Then we could just ship
library/Cargo.toml alongside the lockfile.
It turns out that you can totally reuse the global Cargo.lock inside libstd (Cargo will delete all unused entries, but still uses the others).
Only problem is that it has to be copied into the libstd sources, so we'd end up editing the rust-src component.