Tracking Issue for build-std-always

This is a tracking issue for the RFC "3874" (rust-lang/rfcs#3874).

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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement the RFC
  • Task breakdown: https://hackmd.io/@adamgemmell/By9OyylUbx
• Adjust documentation (see instructions on rustc-dev-guide)
• N/A Style updates for any new syntax (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• What should the build-std.when configuration in .cargo/config.toml be named?
• What should the "always" and "never" values of build-std be named?
• What should build-std.crates be named?
• Should the standard library inherit RUSTFLAGS?
• Should rust-src be a default component?
• Should cargo clean delete builds of the standard library?
  • Should cargo clean with the -p flag be able to selectively choose standard library dependencies?

Implementation history

• Custom JSON target destabilization (see https://github.com/rust-lang/rust/issues/151528)

Read RFC 3874 and the linked task breakdown first; this is a broad tracking issue rather than a self-contained task. Review the unresolved questions about .cargo/config.toml, build-std values and crates, RUSTFLAGS, rust-src, and cargo clean, then consult the rustc-dev-guide stabilization and documentation instructions. Done requires the implementation, documentation, and stabilization checklist items to be completed.