commit | 230d0a3063fca4da9c67377d6bc357cd346f2656 | [log] [tgz] |
---|---|---|
author | bors <bors@rust-lang.org> | Fri Aug 15 12:35:09 2025 +0000 |
committer | bors <bors@rust-lang.org> | Fri Aug 15 12:35:09 2025 +0000 |
tree | 2578e3c21a4eeb99e7beb545a8a52b53388252b2 | |
parent | 2446ebf10514d79268e0195c5b535502809d6a29 [diff] | |
parent | 1a078ff398898a60aa3dc6680b1e0919c891540a [diff] |
Auto merge of #144991 - lcnr:ignore-usages-from-ignored-candidates, r=BoxyUwU ignore head usages from ignored candidates Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/210. The test now takes 0.8s to compile, which seems good enough to me. We are actually still walking the entire graph here, we're just avoiding unnecessary reruns. The basic idea is that if we've only accessed a cycle head inside of a candidate which didn't impact the final result of our goal, we don't need to rerun that cycle head even if is the used provisional result differs from the final result. We also use this information when rebasing goals over their cycle heads. If a goal doesn't actually depend on the result of that cycle head, rebasing always succeeds. However, we still need to make sure we track the fact that we relied on the cycle head at all to avoid query instability. It is implemented by tracking the number of `HeadUsages` for every head while evaluating goals. We then also track the head usages while evaluating a single candidate, which the search graph returns as `CandidateHeadUsages`. If there is now an always applicable candidate candidate we know that all other candidates with that source did not matter. We then call `fn ignore_candidate_head_usages` to remove the usages while evaluating this single candidate from the total. If the final `HeadUsages` end up empty, we know that the result of this cycle head did not matter when evaluating its nested goals.
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-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
Each page has a TOC that is automatically generated by pagetoc.js
. There is an associated pagetoc.css
, for styling.
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.