@@ -10,7 +10,8 @@ compiler is doing a particular thing.
10
10
[ `debug!` ] : https://docs.rs/tracing/0.1/tracing/macro.debug.html
11
11
12
12
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 ) .
14
15
15
16
## Function level filters
16
17
@@ -166,17 +167,23 @@ config.toml.
166
167
## Logging etiquette and conventions
167
168
168
169
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.
173
178
174
179
It may be preferrable to use ` trace! ` over ` debug! ` for very noisy logs.
175
180
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 ` .
178
184
Within functions, prefer ` debug!(?variable.field) ` over ` debug!("xyz = {:?}", variable.field) `
179
185
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 ) .
180
187
181
188
One thing to be ** careful** of is ** expensive** operations in logs.
182
189
@@ -186,9 +193,12 @@ If in the module `rustc::foo` you have a statement
186
193
debug! (x = ? random_operation (tcx ));
187
194
```
188
195
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 ` .
191
199
192
200
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.
194
202
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