Possibly publish a synthetic Cargo.toml.

[ehuss]

The current implementation must construct a fake Cargo.toml virtual workspace for the standard library. This requires knowing about some implementation details like the rustc-std-workspace patches. I think it would be better if the rust-src component included a generated Cargo.toml that contained the bare minimum for the workspace. Then, Cargo would not need to know about some things like these patch hacks.

In addition (or instead), find a way to avoid the patches altogether.

[alexcrichton]

I suspect that synthesizing a Cargo.toml may be quite difficult to do robustly, so I think I'd prefer personally if we can get rid of [patch]. The only reason that exists is to compile crates from crates.io as part of libstd, but it's just sort of a hack around Cargo not being "std aware" but that's what this whole feature is about!

I think we should ideally shoot for a world where this whole rustc-dep-of-std thing goes away. We could, for example, assume that #5 is implemented and we could change:

[dependencies]
core = { version = "1.0.0", optional = true, package = 'rustc-std-workspace-core' }
compiler_builtins = { version = '0.1.2', optional = true }

[features]
rustc-dep-of-std = ['core', 'compiler_builtins']

... to ...

[dependencies]
core = { sysroot = true }
compiler_builtins = { sysroot = true }

Here we can definitely see how when Cargo builds libstd it knows exactly what dependencies to synthesize. For example cfg-if says it loads core from the sysroot, so therefore Cargo draws a dependency from cfg-if to the core in the sysroot source.

This does also mean that rustbuild itself (Rust's build system) would need to use -Z build-std (or something like it) to build libstd.

Overall I think this would get us to a world where [patch] goes away, and otherwise having stable locations in the source code of rust-lang/rust for the locations of crates I think is a reasonable-ish requirement. I think they've literally never changed in almost a decade!

[weihanglo]

If I understand correctly, this issue has been resolved already by these pull requests?

• fix(build-std): remove hack on creating virtual std workspace  cargo#14358
• Move the standard library to a separate workspace  rust#128534

[ehuss]

Yea, I think this is effectively resolved. There are still patches, but at least cargo doesn't need to explicitly know about them anymore. Removal of rustc-dep-of-std is tracked in #51.