tracing-subscriber: impl LookupSpan for Box<LS> and Arc<LS>

[jswrenn]

These implementations mirror those provided by tracing-core for Collect on Box<C> and Arc<C>.

[jswrenn]

This change is unrelated, but included here because I noticed that

$ cargo build --no-default-features --features alloc

was failing without it.

[jswrenn]

@hawkw Would it also be possible to backport this and release in the near future? My only real two blockers for tokio-rs/console#363 are this PR and #2229 (which you've already backported, and is just pending release)!

[hawkw]

looks good to me, thank you! i'll take care of the backports

[jswrenn]

@hawkw Hm, unfortunately, I just discovered a shortcoming of this PR. Since LookupSpan provides a default implementation of LookupSpan::register_filter, I (incorrectly) did not try to implement it myself. So, this PR provides only the stub implementation of LookupSpan::register_filter, which simply panics. Unfortunately, it's impossible to simply 'forward' the method call to the underlying subscriber, as this PR does for LookupSpan::{span,span_data}, because register_filter consumes an &mut self, and there's no (safe) way to go from &mut Arc<T> to &mut T.

I think the impl provided by this PR is probably better-than-nothing for v0.1.x, but for the master branch, it might be more sensible to provide the impl instead for Arc<RwLock<S>> — or to consider having LookupSpan::register_filter consume &self, instead.

[hawkw]

Ah, yeah, I had forgotten about that --- I believe there was actually a similar implementation previously that was removed for the exact reason you're referring to. I think we probably don't want to publish an implementation of LookupSpan for Arc<T> that's broken, so we may need to revert that part of the change.

However, I will note that

there's no (safe) way to go from &mut Arc<T> to &mut T.

isn't actually correct: Arc::get_mut exists, and will (safely) mutably borrow the Arc's contents if it is the only clone of that Arc that exists. Sadly, I don't think an implementation that uses this will be particularly useful in this case, since the Arced LookupSpan type will generally be cloned prior to adding additional Layers to it, as it would be much more difficult to extract just the Arced type to clone it after the Layers are added. If we could trust that code using an Arc<T> subscriber would only clone the Arc by downcasting a whole subscriber stack to an Arc<T> and cloning it only after all layers are added, we could potentially release a LookupSpan impl for Arc<T> that uses Arc::get_mut...but I'm not sure if we can rely on most code that would use this having that shape...

Alternatively, your other suggestion about changing register_filter to take an immutably-borrowed receiver is also worth exploring --- there's a similar discussion around the on_layer callback, where register_filter gets called: #2101 so in tracing-subscriber 0.4, we might end up changing those hooks to take immutably-borrowed receivers...