# Contributor Office Hours Past Sessions

## 2022-11-09

### Lesson Learned / What do you wish you knew?

Matthew perez: Not exactly about bootstrapping: any advice of things you wish you had known

pnkfelix: reduce cycle time! its worth the upfront investment of time to figure out how to do it and what options you have to make things go faster.

pnkfelix: leverage `debug!` output and pretty-printing of compiler's IR's (in tandem)

pnkfelix: learn how to reduce your example source inputs *fully*, including removing their dependence on `std`, and `core` via `#[!no_std]` and `![no_core]`.

### Source Code Reduction

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

see also creduce

### Any tricks for getting started

Matthew Perez: when one starts learning Rust, one often learns to use things like `unwrap()` just as a way to focus on certain topics, and delay learning about everything else (e.g. the `?` operator) until later. Is there an analogous set of tricks for learning about the compiler?

pnkfelix: When you're investigating, don't be afraid to hard code references to deterministically determined data, such as Node Ids. Of course you would never see such things checked into the github repository; but for local development it can be a crucial way to get focused information on something of interest

pnkfelix: it *does* need to be *deterministic* data, which means some quantities shouldn't be used (e.g. the current time of day, and maybe not memory addresses; however, tools like `rr` can make it possible to even use *those* as reference points, if you're willing to do your instrumentation within a debugger like `gdb`/`lldb` or pernos.co

pnkfelix advertises/demonstrates pernos.co once again

pnkfelix: -Z treat-err-as-bug
pnkfelix: `#[rustc_error]`

### Compiling the compiler

vincenzo: re-factoring HIR. hitting problems; and then rebuilds take >30 minutes. Any advice?

pnkfelix (after confirming that vincenzo is just running `x.py build`): Watch my video! In particular, `--keep-stage 1` will be an important component of what you are trying to do. For work like refactoring, you should actually start with a clean checkout, do a full build up to the standard library, and then do all your development with `--keep-stage 1`; that way, the changes you are making will not propagate into the builds of `core` and `std`, and instead you can focus your attention on individual test cases and seeing how they break.