| commit | d11dbbb02905535a89393e80c24274bee81fa928 | [log] [tgz] |
|---|---|---|
| author | bors <bors@rust-lang.org> | Wed Jul 23 23:19:41 2025 +0000 |
| committer | bors <bors@rust-lang.org> | Wed Jul 23 23:19:41 2025 +0000 |
| tree | f39d31e8717fa9446e789dde55a1db2536988fed | |
| parent | ff93b363d7033505d6fa6e21761c41df959691f5 [diff] | |
| parent | 599ee17eb87c83f97eb37fd9fe264da65d4c9461 [diff] |
Auto merge of #144244 - jieyouxu:pr-full-ci, r=Kobzol Enforce that PR CI jobs are a subset of Auto CI jobs modulo carve-outs ### Background Currently, it is possible for a PR with red PR-only CI to pass Auto CI, then all subsequent PR CI runs will be red until that is fixed, even in completely unrelated PRs. For instance, this happened with PR-CI-only Spellcheck (rust-lang/rust#144183). See more discussions at [#t-infra > Spellcheck workflow now fails on all PRs (tree bad?)](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spellcheck.20workflow.20now.20fails.20on.20all.20PRs.20.28tree.20bad.3F.29/with/529769404). ### CI invariant: PR CI jobs are a subset of Auto CI jobs modulo carve-outs To prevent red PR CI in completely unrelated subsequent PRs and PR CI runs, we need to maintain an invariant that **PR CI jobs are a subset of Auto CI jobs modulo carve-outs**. This is **not** a "strict" subset relationship: some jobs necessarily have to differ under PR CI and Auto CI environments, at least in the current setup. Still, we can try to enforce a weaker "subset modulo carve-outs" relationship between CI jobs and their corresponding Auto jobs. For instance: - `x86_64-gnu-tools` will have `auto`-only env vars like `DEPLOY_TOOLSTATES_JSON: toolstates-linux.json`. - `tidy` will want to `continue_on_error: true` in PR CI to allow for more "useful" compilation errors to also be reported, whereas it should be `continue_on_error: false` in Auto CI to prevent wasting Auto CI resources. The **carve-outs** are: 1. `env` variables. 2. `continue_on_error`. We enforce this invariant through `citool`, so only affects job definitions that are handled by `citool`. Notably, this is not sufficient *alone* to address the CI-only Spellcheck issue (rust-lang/rust#144183). To carry out this enforcement, we modify `citool` to auto-register PR jobs as Auto jobs with `continue_on_error` overridden to `false` **unless** there's an overriding Auto job for the PR job of the same name that only differs by the permitted **carve-outs**. ### Addressing the Spellcheck PR-only CI issue Note that Spellcheck currently does not go through `citool` or `bootstrap`, and is its own GitHub Actions workflow. To actually address the PR-CI-only Spellcheck issue (rust-lang/rust#144183), and carry out the subset-modulo-carve-outs enforcement universally, this PR additionally **removes the current Spellcheck implementation** (a separate GitHub Actions Workflow). That is incompatible with Homu unless we do some hacks in the main CI workflow. This effectively partially reverts rust-lang/rust#134006 (the separate workflow part, not the tidy extra checks component), but is not prejudice against relanding the `typos`-based spellcheck in another implementation that goes through the usual bootstrap CI workflow so that it does work with Homu. The `typos`-based spellcheck seems to have a good false-positive rate. Closes rust-lang/rust#144183. --- r? infra-ci
This is a collaborative effort to build a guide that explains how rustc works. The aim of the guide is to help new contributors get oriented to rustc, as well as to help more experienced folks in figuring out some new part of the compiler that they haven't worked on before.
You can read the latest version of the guide here.
You may also find the rustdocs for the compiler itself useful. Note that these are not intended as a guide; it‘s recommended that you search for the docs you’re looking for instead of reading them top to bottom.
For documentation on developing the standard library, see std-dev-guide.
The guide is useful today, but it has a lot of work still to go.
If you‘d like to help improve the guide, we’d love to have you! You can find plenty of issues on the issue tracker. Just post a comment on the issue you would like to work on to make sure that we don't accidentally duplicate work. If you think something is missing, please open an issue about it!
In general, if you don't know how the compiler works, that is not a problem! In that case, what we will do is to schedule a bit of time for you to talk with someone who does know the code, or who wants to pair with you and figure it out. Then you can work on writing up what you learned.
In general, when writing about a particular part of the compiler's code, we recommend that you link to the relevant parts of the rustc rustdocs.
To build a local static HTML site, install mdbook with:
cargo install mdbook mdbook-linkcheck2 mdbook-toc mdbook-mermaid
and execute the following command in the root of the repository:
mdbook build --open
The build files are found in the book/html directory.
We use mdbook-linkcheck2 to validate URLs included in our documentation. Link checking is not run by default locally, though it is in CI. To enable it locally, set the environment variable ENABLE_LINKCHECK=1 like in the following example.
ENABLE_LINKCHECK=1 mdbook serve
We use mdbook-toc to auto-generate TOCs for long sections. You can invoke the preprocessor by including the <!-- toc --> marker at the place where you want the TOC.
This repository is linked to rust-lang/rust as a josh subtree. You can use the rustc-josh-sync tool to perform synchronization.
You can find a guide on how to perform the synchronization here.