Apply feedback

This commit is contained in:
mejrs 2022-12-17 22:51:42 +01:00 committed by Tshepang Mbambo
parent 43cd55066d
commit faf9268f07
2 changed files with 4 additions and 4 deletions

View File

@ -128,7 +128,7 @@ fn main() {
}
```
```bash
```
$ rustc +stage1 error.rs
error[E0277]: cannot add `()` to `{integer}`
--> error.rs:2:7
@ -143,7 +143,7 @@ error: aborting due to previous error
Now, where does the error above come from?
```bash
```
$ RUST_BACKTRACE=1 rustc +stage1 error.rs -Z treat-err-as-bug
error[E0277]: the trait bound `{integer}: std::ops::Add<()>` is not satisfied
--> error.rs:2:7
@ -190,7 +190,7 @@ Cool, now I have a backtrace for the error!
`-Z track-diagnostics` can help figure out where errors are emitted. It uses `#[track_caller]`
for this and prints its location alongside the error:
```bash
```
$ RUST_BACKTRACE=1 rustc +stage1 error.rs -Z track-diagnostics
error[E0277]: cannot add `()` to `{integer}`
--> src\error.rs:2:7

View File

@ -287,7 +287,7 @@ There are three main ways to find where a given error is emitted:
- The _construction_ of the error is far away from where it is _emitted_,
a problem similar to the one we faced with the `grep` approach.
In some cases, we buffer multiple errors in order to emit them in order.
- Invoking `rustc` with the nightly-only flag `-Z track-diagnostics` will print error creation
- Invoking `rustc` with `-Z track-diagnostics` will print error creation
locations alongside the error.
The regular development practices apply: judicious use of `debug!()` statements