Allow disabling LLVM assertions in rustc (fixes #15548)

[nox]

This change is 

[highfive]

Heads up! This PR modifies the following files:

• @wafflespeanut: python/servo/command_base.py, python/servo/bootstrap_commands.py

[SimonSapin]

I got some numbers on Servo commit 09d88cb with Rust commit rust-lang/rust@025c328, on a fast desktop. My config has incremental compilation and ccache enabled. Timings do not include downloading and unpacking dependencies or a compiler.

• Debug, llvm-assertions = true, after cargo clean: 385 secs
• Debug, llvm-assertions = true, after touch components/style/lib.rs: 87 secs
• Debug, llvm-assertions = false, after cargo clean: 333 secs
• Debug, llvm-assertions = false, after touch components/style/lib.rs: 86 secs
• Release, llvm-assertions = true, after cargo clean: 583 secs
• Release, llvm-assertions = true, after touch components/style/lib.rs: 67 secs
• Release, llvm-assertions = false, after cargo clean: 380 secs
• Release, llvm-assertions = false, after touch components/style/lib.rs: 69 secs

Observations:

• With an empty incremental compilation cache (or, presumably, with incremental compilation disabled), LLVM assertions add 16% to the compilation time in debug mode, 53% (!) in release mode.
• With an ideal incremental compilation cache (nothing actually changed other than a source timestamp), LLVM assertions make no difference (beyond noise levels). I think this is because LLVM is not used at all in this scenario
• With an ideal incremental compilation cache, release mode 23% is faster to compile than debug mode! I have no explanation for this.

[SimonSapin]

This PR doesn’t change the default config, so unless you tweak .servobuild it’s just a rustup.

@bors-servo r+

[bors-servo]

📌 Commit 09d88cb has been approved by SimonSapin

[bors-servo]

⌛ Testing commit 09d88cb with merge eec47bb...

[bors-servo]

💔 Test failed - linux-dev

[SimonSapin]

error: compile-fail/privatize.rs:10: unexpected "error": '10:10: 10:26: proc-macro derive panicked'
error: compile-fail/privatize.rs:10: expected error not found: custom derive attribute panicked
error: compile-fail/ban.rs:14: unexpected "error": '14:10: 14:21: Banned type Cell<JSVal> detected. Use MutJS<JSVal> instead'
error: compile-fail/ban.rs:14: expected error not found: Banned type Cell<JSVal> detected. Use MutJS<JSVal> instead,
error: compile-fail/ban-domrefcell.rs:15: unexpected "error": '15:10: 15:30: Banned type DOMRefCell<JS<T>> detected. Use MutJS<JS<T>> instead'
error: compile-fail/ban-domrefcell.rs:15: expected error not found: Banned type DOMRefCell<JS<T>> detected. Use MutJS<JS<T>> instead,

[SimonSapin]

@bors-servo r+

[bors-servo]

📌 Commit 57fd45a has been approved by SimonSapin

[bors-servo]

⌛ Testing commit 57fd45a with merge 4f10a0f...

[bors-servo]

☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css, mac-rel-wpt1, mac-rel-wpt2, windows-gnu-dev, windows-msvc-dev
Approved by: SimonSapin
Pushing 4f10a0f to master...

[mbrubeck]

With an ideal incremental compilation cache, release mode 23% is faster to compile than debug mode! I have no explanation for this.

Conditional compilation means we tend to compile less code in release mode (due to assertions and logging being omitted), though I'm surprised it makes this much difference.

LLVM assertions add 16% to the compilation time in debug mode, 53% (!) in release mode.

This probably means that most of the assertions are in code that is only run during release builds, so enabling assertions during debug builds will be of much more limited use for finding LLVM bugs.