From f1a463aeb548615e0a24222b8da9f211fba03a30 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Sat, 11 Jun 2022 13:55:31 +0200 Subject: [PATCH 1/3] small improves Also, RUST_BACKTRACE=full is now default --- src/diagnostics.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index dbf5cf99e..61c080ac4 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -273,18 +273,19 @@ 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 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 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 - 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 - something else if you whish to trigger on a later error. Some limitations + something else if you whish to trigger on a later error. One limitation 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 + they get inlined in the compiled `rustc`. + Another limitation is the same problem we faced with the prior approach, where the _construction_ of the error is far away from - where it is _emitted_. In some cases we buffer multiple errors in order to + where it is _emitted_. In some cases, we buffer multiple errors in order to emit them in order. The regular development practices apply: judicious use of `debug!()` statements From 2cba1c6471e13df82971245bcad2bc4126733127 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 10:27:02 +0200 Subject: [PATCH 2/3] Update src/diagnostics.md Co-authored-by: Yuki Okushi --- src/diagnostics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 61c080ac4..57e955caf 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -280,7 +280,7 @@ There are two main ways to find where a given error is emitted: will treat the first error being emitted as an Internal Compiler Error, which allows you to get a 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. One limitation + something else if you wish to trigger on a later error. One limitation with this approach is that some calls get elided from the stack trace because they get inlined in the compiled `rustc`. Another limitation is the same problem we faced with From ea4b60dfeb910fd2be397796dbfcd89e059a39d7 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Tue, 21 Jun 2022 11:15:21 +0200 Subject: [PATCH 3/3] address review comment --- src/diagnostics.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/src/diagnostics.md b/src/diagnostics.md index 57e955caf..0f0bfd895 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -280,13 +280,13 @@ There are two main ways to find where a given error is emitted: will treat the first error being emitted as an Internal Compiler Error, which allows you to get a stack trace at the point the error has been emitted. Change the `1` to - something else if you wish to trigger on a later error. One limitation - with this approach is that some calls get elided from the stack trace because - they get inlined in the compiled `rustc`. - Another limitation is the same problem we faced with - the prior approach, where the _construction_ of the error is far away from - where it is _emitted_. In some cases, we buffer multiple errors in order to - emit them in order. + something else if you wish to trigger on a later error. + + There are limitations with this approach: + - Some calls get elided from the stack trace because they get inlined in the compiled `rustc`. + - 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. 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