Previously, the errors looked like this:
```
$ cargo check
Checking std v0.0.0 (/home/joshua/rustc/library/std)
error: duplicate lang item in crate `core`: `bool`.
|
= note: the lang item is first defined in crate `core` (which `std` depends on)
= note: first definition in `core` loaded from /home/joshua/.local/lib/cargo/target/debug/deps/libcore-afaeeb022194dcf3.rmeta
= note: second definition in `core` loaded from /home/joshua/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-2675a9a46b5cec89.rlib
error[E0119]: conflicting implementations of trait `ffi::c_str::CString::new::SpecIntoVec` for type `&str`:
--> library/std/src/ffi/c_str.rs:392:9
|
379 | impl<T: Into<Vec<u8>>> SpecIntoVec for T {
| ---------------------------------------- first implementation here
...
392 | impl SpecIntoVec for &'_ str {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `&str`
|
= note: upstream crates may add a new impl of trait `core::convert::Into<alloc_crate::vec::Vec<u8>>` for type `&str` in future versions
error: aborting due to 119 previous errors; 93 warnings emitted
```
Now, they're much more helpful:
```
$ cargo check
Compiling core v0.0.0 (/home/joshua/rustc2/library/core)
error: failed to run custom build command for `core v0.0.0 (/home/joshua/rustc2/library/core)`
Caused by:
process didn't exit successfully: `/home/joshua/.local/lib/cargo/target/debug/build/core-ea3b18d34c1ee1c8/build-script-build` (exit code: 101)
--- stderr
error: you are attempting to build libcore without going through bootstrap
help: use `x.py build --stage 0 library/std`, not `cargo build`
help: use `x.py check`, not `cargo check`
note: if you're sure you want to do this, use `RUSTC_BOOTSTRAP=0` or some other dummy value
thread 'main' panicked at 'explicit panic', library/core/build.rs:7:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
The metric here is 'did you set RUSTC_BOOTSTRAP'; if so, it's assumed
you know what you're doing and no error is given. It's very unlikely (or
at least should be!) that someone will have RUSTC_BOOTSTRAP globally
set, so I think this is a good heuristic.