As a pretty new rustc dev, I wanted to share some of my experiences here and see if we can brainstorm ways to help improve things for other people who want to contribute.
Before I get started: I know that “compilers are hard”. While some complexity is inherent, I suspect that some of this might be fixable with better docs, improvements to the makefiles, etc.
Trying to use the current makefiles can get frustrating if you need to build/test specific things. I can learn some of the basic incantations like “make rustc-stage1 -j4” to get a working compiler I can play with rather than having to wait for the whole build cycle. It’s great that we let people stop at a particular stage and only build certain artifacts.
That said, it’s difficult to predict how to run parts of the test suite. There’s a great command “make tips” (yay!) that helps you get started. Unfortunately, the use of abbreviations is unpredictable and no master list is given in the Makefile. Eg it’s not “make check-stage1-run-pass” it’s “make check-stage1-rpass”. What about running the core tests? “make check-stage1-coretesttest” or “make check-stage1-coretest”? Or syntax tests? “make check-stage1-syntaxtests” or “make check-stage1-syntax” or “make check-stage-stest”? You get the picture. There are some easy fixes for this, eg putting the master list in the Makefile or by naming the test groups in a predictable way.
Equally puzzling is that “make check” doesn’t seem to run all the tests, or doesn’t appear to. This may be related to another issue listed here (see “debugging issues” below) which may be prematurely making “make check” seem complete when it isn’t. If that’s the case, we may want to have “make check” spit out a full summary even if run with -j4.
Some tests, like the check-docs tests, don’t run via “make check” by design. If that’s still the case, it would make sense to bring all the tests under one umbrella. Basically, the command would be “make check-everything-travis-will-complain-about”
There’s a known issue that lldb tests don’t appear work on the latest OS X (https://github.com/rust-lang/rust/issues/32520). This seems to make “make check” not complete successfully and miss important tests that travis later complains about. Until it’s resolved, we may want to reorder the tests so that the test groups we know are broken on some platforms run last.
The next issue, assuming this has been fixed, is that compiling a debug-able compiler can be slow if you don’t pass the right set of flags. Here again, I think we could have Makefile (or rustbuild) come to the rescue. By default, if ‘make rustc-stage1’ built a debugging compiler that was optimized to the point of being “fast enough” this seems like a win-win.
Unfortunately, between having problems putting together a debug-able compiler and the issues with lldb I ended up just resorting to println debugging. As you can imagine, that plus the long compile cycle times makes for a very slow process.
Assuming rustc could be debugged by default, something I liked about working on the chapel compiler is that you can start debugging the compiler in one step. By passing an additional commandline option to the compiler, it would start itself inside of gdb and load all the additional helper commands that let you inspect known compiler data structures. As you can imagine, this helps you shave off lots of time trying to ferret out tricky bugs.
Yup, I know this is a tricky problem to solve, but it’s still worth a mention. If you want to fix a bug and see if you got it right, you may have to wait 8-10 minutes if it shows up in stage 1 (say, if you’re editing libsyntax) or tens of minutes if it shows up in stage 2. Asking around, this isn’t going to get better with incremental compilation because - as I understand it - you can’t save off some of the previous compiler build. You have to start from scratch each time.
The issue here is basic mechanics. Waiting that long to see if a bug is fixed minimizes the amount you can get done to something like 8 fix attempts/day when you count the full compile/test time.
I mentioned this to a coworker and they said “just work on multiple branches at a time”. In my experience, this advice is only feasible with multiple computers, as running a make with -j4 on this laptop brings it to a crawl.
Like I said, I totally get that working on a compiler is very much a “working in the mud” endeavor. But I get a sense that some of these rough edges can be fixed, and it’ll help bring new people on-board.