Document dist components we ship

[jieyouxu]

E.g. #138647.

We should document:

• What each dist component is intended for?
• What guarantees do we have for dist components?
  • Directory structure?
  • Archive format?
  • Buildability?
  • Other properties?
  • Stability?
• Are there any test coverage for said dist components? cf. Tracking issue for better testing for dist artifacts #136822.

[jieyouxu]

cc @Mark-Simulacrum: you might be someone who have some clues about what the purposes of the (less obvious) dist components we ship are... Are there any docs or historical discussions that you know of for them?

[Mark-Simulacrum]

Historical discussions are probably just in the PR(s) that landed them if anywhere. I can try to get a PR out for the steps in dist.rs in bootstrap having doc comments perhaps, as a starting point? Unless we want the docs to live elsewhere -- depends I guess how much this is externally guaranteed vs. useful for ourselves.

[jieyouxu]

Yeah, part of this is I don't actually know what we do guarantee, be it external or internal (often by implicit assumptions). For instance, I think miri depends on rustc-dev, so even if it's technically "internal" it's still logistically depended upon.

cc @RalfJung is that description accurate for miri?

[RalfJung]

I don't know what you mean by "internal" vs "external", but all tools that use the rustc driver depend on rustc-dev -- we have some of those in-tree (Miri, clippy), and there's plenty more out-of-tree (e.g. all the verification tools, minirust, and I guess klint as well).

[jieyouxu]

I don't know what you mean by "internal" vs "external", but all tools that use the rustc driver depend on rustc-dev -- we have some of those in-tree (Miri, clippy), and there's plenty more out-of-tree (e.g. all the verification tools, minirust, and I guess klint as well).

I don't think the distinction matters that much tbh, since if the rustc-dev component breaks our toolchain breaks (let alone other out-of-tree tools that depend on it) so...

[ehuss]

The components are lightly documented at https://rust-lang.github.io/rustup/concepts/components.html.

Things like llvm-tools was accidentally "stabilized" due to a bug, and how people were using it. There are more questions and context in #85658, but so far the compiler team has not been able to answer the questions about it.