Description
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.
Sub-issues
Sub-issues
- Manage this item control shift u
Metadata
Metadata
Assignees
Labels
Area: dist components, e.g. `rustc-dev`, `rustc-src`, etc.Area: Documentation for any part of the project, including the compiler, standard library, and toolsCategory: An issue tracking the progress of sth. like the implementation of an RFCRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the compiler team, which will review and decide on the PR/issue.Relevant to the release subteam, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
jieyouxu commentedon May 22, 2025
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 commentedon May 22, 2025
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 commentedon May 22, 2025
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 commentedon May 22, 2025
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 commentedon May 22, 2025
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 commentedon May 22, 2025
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.