Skip to content

Commit 72906c9

Browse files
oli-obkjyn514
authored andcommitted
Address review comments
1 parent dc16b52 commit 72906c9

File tree

1 file changed

+20
-10
lines changed

1 file changed

+20
-10
lines changed

Diff for: src/tracing.md

+20-10
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,8 @@ compiler is doing a particular thing.
1010
[`debug!`]: https://docs.rs/tracing/0.1/tracing/macro.debug.html
1111

1212
To see the logs, you need to set the `RUSTC_LOG` environment variable to your
13-
log filter.
13+
log filter. The full syntax of the log filters can be found in the [rustdoc
14+
of `tracing-subscriber`](https://docs.rs/tracing-subscriber/0.2.24/tracing_subscriber/filter/struct.EnvFilter.html#directives).
1415

1516
## Function level filters
1617

@@ -166,17 +167,23 @@ config.toml.
166167
## Logging etiquette and conventions
167168

168169
Because calls to `debug!` are removed by default, in most cases, don't worry
169-
about adding "unnecessary" calls to `debug!` and leaving them in code you
170-
commit - they won't slow down the performance of what we ship, and if they
171-
helped you pinning down a bug, they will probably help someone else with a
172-
different one.
170+
about the performance of adding "unnecessary" calls to `debug!` and leaving them in code you
171+
commit - they won't slow down the performance of what we ship.
172+
173+
That said, there can also be excessive tracing calls, especially
174+
when they are redundant with other calls nearby or in functions called from
175+
here. There is no perfect balance to hit here, and is left to the reviewer's
176+
discretion to decide whether to let you leave `debug!` statements in or whether to ask
177+
you to remove them before merging.
173178

174179
It may be preferrable to use `trace!` over `debug!` for very noisy logs.
175180

176-
A loosely followed convention is to use `#[instrument(level = "debug")]` in
177-
favour of `debug!("foo(...)")` at the start of a function `foo`.
181+
A loosely followed convention is to use `#[instrument(level = "debug")]`
182+
([also see the attribute's documentation](https://docs.rs/tracing-attributes/0.1.17/tracing_attributes/attr.instrument.html))
183+
in favour of `debug!("foo(...)")` at the start of a function `foo`.
178184
Within functions, prefer `debug!(?variable.field)` over `debug!("xyz = {:?}", variable.field)`
179185
and `debug!(bar = ?var.method(arg))` over `debug!("bar = {:?}", var.method(arg))`.
186+
The documentation for this syntax can be found [here](https://docs.rs/tracing/0.1.28/tracing/#recording-fields).
180187

181188
One thing to be **careful** of is **expensive** operations in logs.
182189

@@ -186,9 +193,12 @@ If in the module `rustc::foo` you have a statement
186193
debug!(x = ?random_operation(tcx));
187194
```
188195

189-
Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::bar`, then
190-
`random_operation()` will run.
196+
Then if someone runs a debug `rustc` with `RUSTC_LOG=rustc::foo`, then
197+
`random_operation()` will run. `RUSTC_LOG` filters that do not enable this
198+
debug statement will not execute `random_operation`.
191199

192200
This means that you should not put anything too expensive or likely to crash
193-
there - that would annoy anyone who wants to use logging for their own module.
201+
there - that would annoy anyone who wants to use logging for that module.
194202
No-one will know it until someone tries to use logging to find *another* bug.
203+
204+
[`tracing`]: https://docs.rs/tracing

0 commit comments

Comments
 (0)