Skip to content

Tracking issue for high-level compiler overview rework #2116

Open
@jieyouxu

Description

@jieyouxu

This is a tracking issue for high-level compiler overview chapter rework. This is not a serious r-l/r kind of tracking issue, so discussions/feedback/suggestions totally welcomed (opening issues for specific topics also great)!

TODO: I plan to edit this issue soon, opening now so I don't forgor.

Rationale

TODO

Implementation steps

TODO: fill out this section a bit more

  • Identify the intended audience.
    • Ideally, it should be useful to both new contributors and veteran contributors alike! Even veteran contributors will have areas they don't know well about, and this should equally cater to them.
  • Determine a suitable overall structure for the overview. How do we introduce rustc to an interested contributor who never read rustc's source to help them aboard?
    • Current idea: I plan to describe rustc as a "cute little command-line tool that gradually lowers from one intermediate representation to another, but with a starting input of 'source code' and output of 'machine code'"1
    • How does this compare to the previous idea of information flow between crates sub-systems? It's more faithful to what actually happens and is compatible with query system being not coarse-grained IR-to-IR-in-fullness (i.e. IRs can be gradually lowered, in parts, on demand) and is also compatible with incr comp. It's also less of a spaghetti of arrows if I want to draw some arrows between "nodes" in what I want to describe.
  • Figure out how to talk about cross-cutting subsystems (diagnostics, type checking, traits, lints, error handling, query system)
  • Figure out if we should also have a listing that briefly introduces the intended purpose of each compiler crate 2. For each compiler crate, produce a brief TL;DR:
    • How does it support the lowering and various analyses? What purposes does it serve?
    • How does it fit into the "big picture"?
    • Main entry points? (Link to source code, pinned to specific commit, add a date-check annotation)
  • Actually write the thing.

Related issues

Implementation history

Footnotes

  1. obviously it's more complicated than that, but I personally find significant value in "xxx oversimplified" because having a rough high-level picture makes it easy for you to know what you're getting into, and then to become an expert by knowing all the "but acktually" cases

  2. I'm envisioning a distinction between overview/intro.md versus overview/crates/rustc_middle.md etc. etc. We can also go ask the experts for how they think about each crate (for a smol TL;DR) in (possibly) weekly/monthly dev-guide review sessions!

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions