@@ -273,18 +273,19 @@ There are two main ways to find where a given error is emitted:
273273
274274- ` grep ` for either a sub-part of the error message/label or error code. This
275275 usually works well and is straightforward, but there are some cases where
276- the error emitting code is removed from the code where the error is
276+ the code emitting the error is removed from the code where the error is
277277 constructed behind a relatively deep call-stack. Even then, it is a good way
278278 to get your bearings.
279- - Invoking ` rustc ` with the nightly-only flag ` -Z treat-err-as-bug=1 ` , which
279+ - Invoking ` rustc ` with the nightly-only flag ` -Z treat-err-as-bug=1 `
280280 will treat the first error being emitted as an Internal Compiler Error, which
281- allows you to use the environment variable ` RUST_BACKTRACE=full ` to get a
281+ allows you to get a
282282 stack trace at the point the error has been emitted. Change the ` 1 ` to
283- something else if you whish to trigger on a later error. Some limitations
283+ something else if you whish to trigger on a later error. One limitation
284284 with this approach is that some calls get elided from the stack trace because
285- they get inlined in the compiled ` rustc ` , and the same problem we faced with
285+ they get inlined in the compiled ` rustc ` .
286+ Another limitation is the same problem we faced with
286287 the prior approach, where the _ construction_ of the error is far away from
287- where it is _ emitted_ . In some cases we buffer multiple errors in order to
288+ where it is _ emitted_ . In some cases, we buffer multiple errors in order to
288289 emit them in order.
289290
290291The regular development practices apply: judicious use of ` debug!() ` statements
0 commit comments