feat: allow creating SpanTrace from Span directly

[CAD97]

Motivation

I'm writing a tracing subscriber layer that captures tracing events to display in an in-program UI in a somewhat structured manner; as such I don't want to just use the fmt layer's format-to-a-single-string approach, and instead capture (currently) the event metadata, fields, timestamp, thread, and spantrace, to be displayed in a filterable/searchable/interactable manner later.

Currently, the only way to capture a SpanTrace is via SpanTrace::capture. This (rightfully) captures the SpanTrace of the current execution. However, I'm currently inside Subscribe::on_event; I have the span right here! Even if Span::current happens to be the same during on_event as when the event was fired, it seems more "proper" to create a SpanTrace from the span passed in to me, rather than looking up Span::current.

Solution

The actual code change is almost trivial: all that needs to happen is to expose a SpanTrace::new that takes a Span in addition to the existing SpanTrace::current.

[CAD97]

https://deploy-preview-1492--tracing-rs.netlify.app/tracing_error/struct.spantrace#method.new

(Yes I'm aware that master has introduced breaking changes and I'll either need to backport this (almost trivially) or wait for the ecosystem to update. But I'd also like upstream conformation if this is a reasonable addition (or if I should just use Span::current) before pulling in a patch.)

[yaahc]

looks great to me, but I'll leave the final decision to @hawkw.

[hawkw]

looks good to me, thanks!

[hawkw]

we may also want to add a From<Span> for SpanTrace conversion, but we can do that separately.

[CAD97]

I actually have a reason for not doing so here, though I'm not super certain in the justification:

A SpanTrace is suitably different from Span that I'm not sure that From is clear on the semantics of creating the span trace. While SpanTrace physically only holds onto the single Span, logically the SpanTrace is the whole list of spans, from the innermost span that it holds, to the outermost span. As such, .into() feels a bit wrong.

I think it's fine either way, but that's my reasoning for just providing ::new here.

[hawkw]

yeah, i was on the fence about it — we can always do that separately, if we decide it's worth having? this seems good to me as is.

[CAD97]

Fixed the trailing whitespace fmt error (whoops, blame the GH code editor).

[CAD97]

One small flaw with my plan... subscribe::Context gives a SpanRef, and there doesn't seem to be any consumer-facing way to go from SpanRef to Span.

More specifically, ctx allows getting at the (Id, &'static Metadata<'static>) event's|current span, but as it just holds &'_ impl Collect, there seems to be no way of acquiring the Dispatch required to acquire the full Span.

My problem is ultimately that Subscribe layers are given borrowed access to the collector (via Context), but I want an owning clone to create the owned SpanTrace for the current Event. I would guess that the place to expose that functionality would be SpanRef::to_owned(&self) -> Span or similar, but I'm unsure if that's an API addition that tracing would want to (or even could) do.

(In the meantime I'm just biting the bullet and effectively "pre-rendering" the span trace instead.)