mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

small improves (#1371) 

Co-authored-by: Yuki Okushi <jtitor@2k36.org>
This commit is contained in:
Tshepang Mbambo 2022-06-21 11:45:30 +02:00 committed by GitHub
parent 27b12c37e5
commit 4f9f93c22a
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
src/diagnostics.md
View File

@ -273,19 +273,20 @@ There are two main ways to find where a given error is emitted:
- `grep` for either a sub-part of the error message/label or error code. This - `grep` for either a sub-part of the error message/label or error code. This
usually works well and is straightforward, but there are some cases where usually works well and is straightforward, but there are some cases where
the error emitting code is removed from the code where the error is the code emitting the error is removed from the code where the error is
constructed behind a relatively deep call-stack. Even then, it is a good way constructed behind a relatively deep call-stack. Even then, it is a good way
to get your bearings. to get your bearings.
- Invoking `rustc` with the nightly-only flag `-Z treat-err-as-bug=1`, which - Invoking `rustc` with the nightly-only flag `-Z treat-err-as-bug=1`
will treat the first error being emitted as an Internal Compiler Error, which will treat the first error being emitted as an Internal Compiler Error, which
allows you to use the environment variable `RUST_BACKTRACE=full` to get a allows you to get a
stack trace at the point the error has been emitted. Change the `1` to stack trace at the point the error has been emitted. Change the `1` to
something else if you whish to trigger on a later error. Some limitations something else if you wish to trigger on a later error.
with this approach is that some calls get elided from the stack trace because
they get inlined in the compiled `rustc`, and the same problem we faced with There are limitations with this approach:
the prior approach, where the _construction_ of the error is far away from - Some calls get elided from the stack trace because they get inlined in the compiled `rustc`.
where it is _emitted_. In some cases we buffer multiple errors in order to - The _construction_ of the error is far away from where it is _emitted_,
emit them in order. 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.
The regular development practices apply: judicious use of `debug!()` statements The regular development practices apply: judicious use of `debug!()` statements
and use of a debugger to trigger break points in order to figure out in what and use of a debugger to trigger break points in order to figure out in what