rust-lang / rust-lang/rustc-dev-guide
Explain difference between `rustc_middle::{something}` and `rustc_{something}` in rustc dev guide
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 1.9k
- Forks
- 613
- Avg merge
- 17h 24m
- Merged PRs (30d)
- 39
Description
I think we are all agreed that splitting up rustc_middle would be a good idea
as it would reduce memory usage and increase parallelism when bootstrapping.
Ideally, we would split out each rustc_middle module into its own crate. For
example, rustc_middle::ich would become rustc_ich or something (I'm working
on this right now).
However, a lot of the rustc_middle modules already have crates named after
them:
rustc_middle module |
similarly-named crate |
|---|---|
rustc_middle::arena |
rustc_arena |
rustc_middle:hir |
rustc_hir |
rustc_middle::infer |
rustc_infer |
rustc_middle::lint |
rustc_lint |
rustc_middle::macros |
rustc_macros |
rustc_middle::mir |
rustc_mir |
rustc_middle::query |
rustc_query_system |
rustc_middle::traits |
rustc_traits |
rustc_middle::ty |
rustc_ty |
I believe for the case of rustc_middle::mir -> rustc_mir the difference is
that rustc_middle::mir contains the definition for the MIR and associated code
like the MIR visitors, while rustc_mir contains analysis code (e.g. borrowck),
but I don't know what the differences are for the others. Therefore, my goal
with this meta issue is to collect information about what the differences
are to make it easier to split up rustc_middle.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing each rustc_middle module with its similarly named crate, especially the MIR and rustc_mir distinction described in the issue. Record the purpose and boundaries of each pair, then add the findings to the rustc dev guide so the differences and possible split boundaries are clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100