rustc_resolve: use structured fields in traces #135676
Conversation
rustbot
added
S-waiting-on-review
| "find_span_immediately_after_crate_name: module_name={:?} use_span={:?}", | ||
| module_name, use_span | ||
| ); | ||
| debug!("find_span_immediately_after_crate_name",); |
There was a problem hiding this comment.
there's no need to repeat the name of the function here and elsewhere; please remove.
There was a problem hiding this comment.
What do you think should be the message instead? Something like debug!("entered")?
(in the places where fields are added I can just remove the message)
There was a problem hiding this comment.
not totally certain that they're even adding much value to keep around at all.
There was a problem hiding this comment.
Removed those, then. (and the instrumentation for the containing fns)
There was a problem hiding this comment.
Why remove the instrument annotation. #[instrument(level = "debug", skip(...))] should "just work" without any dummy debug! statement in the body shouldn't it?
There was a problem hiding this comment.
Yes, you're absolutely right. I thought it only created spans but no "enter" event. I was also creating info-level spans by accident. Fixed.
yotamofek
force-pushed
the
resolve-cleanups
branch
3 times, most recently
from
a70ca63 to
5f1bf88
Compare
yotamofek
force-pushed
the
resolve-cleanups
branch
from
5f1bf88 to
539b4d8
Compare
Oh, right, thanks! Fixed. (in two other places too) |
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
Rollup of 5 pull requests Successful merges: - rust-lang#135433 (Add Profile Override for Non-Git Sources) - rust-lang#135626 (doc: Point to methods on `Command` as alternatives to `set/remove_var`) - rust-lang#135658 (Do not include GCC source code in source tarballs) - rust-lang#135676 (rustc_resolve: use structured fields in traces) - rust-lang#135762 (Correct counting to four in cell module docs) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#135676 - yotamofek:resolve-cleanups, r=BoxyUwU rustc_resolve: use structured fields in traces I think this crate was written before `tracing` was adopted, and was manually writing fields into trace logs instead of using structured fields. I kept function names in the trace messages even though I added `#[instrument]` invocations so that the events will be in named spans, wasn't sure if spans are always printed.
I think this crate was written before
tracingwas adopted, and was manually writing fields into trace logs instead of using structured fields.I kept function names in the trace messages even though I added
#[instrument]invocations so that the events will be in named spans, wasn't sure if spans are always printed.