codegen units is quite the same as the `-j` flag
cargo has the `-j` flag and defaults it to #cpus (logical cpus), so it's by default using the most times most optimal choice there
And this will parallelize the compilation of all "jobs", roughly like with make. Where a job is normally (oversimplified) compiling one code unit into one object file (.o).
And cargo does that too.
The problem is that where rust and C/C++ (and I think D) etc. set code unit boundaries differ.
In rust it's per crate. In C/C++ it's (oversimplified!!) per .h+.c file pair.
This has drawbacks and benefits. But one drawback is that it parallelizes less good. Hence why rust internally split one "semantic code unit" into multiple internal code units passed to LLM. So this is an additional level of parallelism to the -j flag.
In general this works fine and if people speak about rust builds being slow it is very rarely related to this aspect. But it puts a limit onto how much code you want in a single crate which people sometimes overlook.
But in the OP article they did run into it due to placing like idk 100k lines of code (with proc macors maybe _way_ more then that) into a single crate. And then also running into a bug where this internal parallelization somehow failed.
Basically imagine 100k+ line of code in a single .cpp file passing `-j` to the build to it will not help ;)
I think one important takeaway is that it could make sense to crate awareness about this by emitting a warning if your crate becomes way to big with a link to a in-depth explanation. Through practically most projects either aren't affected or split it into crates way earlier for various reasons (which sometimes include build time, but related to caching and incremental rebuilds, not fully clean debug builds).