If you're making type-level changes that aren't going to alter functionality, or want to just make sure the whole compiler will build, you can run `x.py check -i` to get the equivalent of `cargo check` outside of the compiler tree.
If you know ahead of time that you're not changing the code generation/ABI of the compiler (metadata, mangling, that sort of thing) then you can also do something like `x.py --keep-stage 0` and work entirely in stage 2 (you wouldn't pass --stage 1 with this option). Alternatively, you can pass `--keep-stage 1` and run the stage 1 tests; this will save you a rebuild of std and test which is often unnecessary after a compiler change.
However, even with these suggestions/hints, building the Rust compiler can be rather slow.
This narrows the time between when you have something to test and when you remember to test it. It saves you wall clock time if not CPU time.
(I highly recommend combining watch with an editor or IDE that saves all buffers at the same time, instead of one at a time).
If the compiler is built in Rust, I guess it would efficiently use several dozens of cores and gigabytes of RAM
Since LDC uses DMD's frontend and LLVM as a backend, it would suggest that LLVM is the bottleneck here. Like LDC, Rust also uses LLVM as a backend. It's well-known that LLVM isn't exactly the nimblest of drivers, but makes up for it with high-quality binaries.
There are tentative future plans for an alternative Rust backend based on Cretonne that, like DMD, would produce slower binaries in exchange for faster compilation: https://internals.rust-lang.org/t/possible-alternative-compi...
And coffee, as that already takes around 5 to 20 minutes depending on what part of the compiler you're touching.
