Tracking Issue for build-std explicit dependencies

[ehuss]

Summary

RFC: #3875
Documentation: TODO

Allows packages to list explicit dependencies on standard library crates.

See also rust-lang/rust#155363 for the build-std-always tracking issue.

Unresolved Issues

• What syntax is used to identify dependencies on the standard library in Cargo.toml?
• What is the format for builtin dependencies in Cargo.lock?
• What syntax is used to patch dependencies on the standard library in Cargo.toml?
• Should implicit standard library dependencies default to public?
• Should explicit standard library dependencies default to private?
• Should we support build-dependencies?
• Should parsed manifests be used instead of the registry index?
• Should cargo metadata include the standard library's dependencies?
• What should the exact format of the pkgid spec for builtin dependencies be?

Future Extensions

• Replace #![no_std] as the source-of-truth for whether a crate depends on std
• Allow unstable crate names to be referenced behind cfgs without requiring nightly
• Allow builtin source replacement
• Remove rustc_dep_of_std
• Allow enabling/disabling features with build-std
• Allow local builds of compiler-rt intrinsics

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.