RustcContributor::* Planning

Cloud Desktop Setup Instructions

See oli-obk's doc: https://hackmd.io/VPGjaYD5Q6u8RbhouDCXWg

How to bound RustcContributor::* facilitator time commitments

One of pnkfelix's main concerns in soliciting people to help act as facilitators (instructors?) is how to predict (and set bounds on) workload.

We can easily set bounds office-hour obligations (namely: just show up at the start time and answer questions for that set period)

But a presentation needs one or two things:
* a plan (i.e., the things you want to cover during the presentation)
* (optional?) prepared/curated content to use in the presentation

Presentation styles

Customized

Some presenters would prefer to prepare their own plan+content, and we should be understand that desire, and figure out way to help such presenters deliver a presentation they'll be happy with without requiring a huge amount of extra effort.

• for example, one way to accomplish this would be to ensure that the presentation material is itself easily modifiable; e.g. a have a policy that the basic slides should be authored in a markdown-based language (but: presenters are still free to import that content into their preferred presentation authoring tool)

Off-the-shelf

Some presenters will not be able to prepare their own plan+content, and will only be able to serve as facillitators if it means they can put in minimal effort before the presentation.

• How minimal?
• E.g. would the cohort feel slighted if a presenter showed up and proceeded to walk through a chapter of the rustc-dev-guide with them?
  • (The end of this document raises this question again below, in light of how we are already in October and thus should be seeking short cuts to get us to deliver something here.)

What we need

DocJones has put together docs that describe:

• the goals (incl inputs+outputs of each program) (see compiler-team#557).
• the draft RFC week-by-week content

Here's what we will eventually need to start things going:

1. Curricula for each program: what is being studied?
   • How should we go about translating from the documented "goals" into appropriate curricula?
2. Overall breakdown into week-by-week content
   • RustcContributor::new has plausible outline in draft RFC week-by-week section.
   • RustcContributor::grow and RustcContributor::explore are progressively less structured.
3. Pre-baked content for each week's session

If we had all three things, then we could immediately start soliciting facilitators, stating "its up to you whether to customize the content, but we don't expect you to spend more than X minutes doing prep work before you run the actual session."

Since we do not have all three items above, we need to either:

• prepare them all ourselves,
• ask for help to generate them,
• or we just use the rustc-dev-guide itself as our initial resource.

Appendices

Week-by-week breakdown

This is adapted from draft RFC week-by-week

• Week 1: Onboarding
  • how to cloud desktop
  • git basics
  • how to build rustc: config.toml, how enable RUSTC_LOG debug output
  • overview of the rustc-dev guide
  • overview of how a Rust crate is structured (since that is what the compiler will need to understand)
  • overview of how rustc is structured
• Week 2: Inspecting
  • General debugging: Minimize input code. Remove other crates if possible. Use #![no_std] if possible.^[1]
  • General debugging: RUSTC_LOG to observe compiler activity. How to add new debug! statements.
  • General debugging: -Z treat-err-as-bug to get a more useful stack-trace into rustc source code.
  • General debugging: pretty-printing AST or other intermediate representations in order to understand compiler internal model of code.
  • Advanced debugging: #[rustc_*] attributes with diagnostics that expose guts of compiler at per-item level.
  • (Advanced?) Debugging: "automatically" identify potentially relevant part of compiler via bisection. How to use cargo-bisect-rustc
• Week 3: Modifying
  • (TODO: Pick a "good" crate and "good" task for beginners. Maybe adding a lint, or modifying a diagnostic?)
  • Note: Recipes for enhancing compiler vs fixing bug in compiler can differ.^[2]
  • One option: Change message wording
  • Another option: Add a NOTE to an existing diagnostic (includes e.g. identifying the span you want to associate with the note)
• Week 4: Testing
  • The src/test/ui testing framework
  • How to write good tests
  • How and when to bless existing tests
  • Other ways to test besides src/test/ui
• Week 5: Upstreaming
  • Opening a PR
  • CI
  • bors
  • try builds
  • perf runs
  • crater runs
• Week 6: Looking back
  • Retrospective
  • any questions from cohort?

---

1. Advanced topic: True minimization might require adding #![feature(..)]'s in order to narrow in on kernel of the bug. ↩︎

2. E.g. enhancing compiler need not always involve changing internal model of code held by rustc, while correcting erroneous behavior often does. (Self-doubt: is this true often enough to be worth even noting?) ↩︎