@@ -273,18 +273,19 @@ There are two main ways to find where a given error is emitted:
273
273
274
274
- ` grep ` for either a sub-part of the error message/label or error code. This
275
275
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
277
277
constructed behind a relatively deep call-stack. Even then, it is a good way
278
278
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 `
280
280
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
282
282
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
284
284
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
286
287
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
288
289
emit them in order.
289
290
290
291
The regular development practices apply: judicious use of ` debug!() ` statements
0 commit comments