David Barsky

Hmm, I'm not entirely sure why this _strictly_ needed as opposed to writing `tracing_opentelemetry::layer().with_filter(filter).with_tracer(tracer)`. (I'm genuinely unsure, so I'd love to get clarification!)

My bad! Running the workflow now.

I _think_ this is a duplicate of https://github.com/tokio-rs/tracing/issues/2448, but I'm thankful you were able to dig into this a little deeper. > The re-entrant call to debug! clobbers this thread-local...

Thanks for the PR. The issue underlying issue is that `tracing_subscriber::fmt::init()` is not equivalent to `tracing_subscriber::fmt().init()`. The former does `RUST_LOG`-based filtering while the latter does not. This is pretty confusing...

Before anything else, I should emphasize that I'm sorry that this was your early/first experience with Rust: it took me several minutes of fiddling in a local repo to figure...

> My recent background is almost entirely in Go where JSON structured logging seems more common, relatively speaking. 👍 > For what it's worth, here's how I instantiate my favorite...

For "reload rust-analyzer reasons when a `TARGETS`/`BUCK` file changes"; this PR is based atop of https://github.com/rust-lang/rust-analyzer/pull/16840.

> Is this now ready for re-review? Almost. I'm got a few things I want to get fixed first, but it should be ready by tomorrow. I'll comment here when...

Alright, this is in a mostly fine state. Here's the situation: - Any build system-specific integrations strings (Buck, Bazel) have been removed and are instead driven through configuration. - The...

Noticed a smaller error in that rust-analyzer assumes an error `source` when, strictly speaking, it doesn't need one.