Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT] registry part 2 #412

Closed
wants to merge 79 commits into from
Closed

[DRAFT] registry part 2 #412

wants to merge 79 commits into from

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Oct 29, 2019

Opening a draft PR to make this easier to comment on, please ignore for now

hawkw and others added 5 commits October 28, 2019 15:40
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: David Barsky <dbarsky@amazon.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: David Barsky <dbarsky@amazon.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/mod.rs Outdated Show resolved Hide resolved
@davidbarsky
Copy link
Member

I can't directly respond, but:

Hmm, I'm surprised this is necessary given that the SpanRef type takes a reference to the registry? Regardless, WDYT about moving this bound to the span method?

I'm as puzzled as you are, but yes—I've moved the where clause to the span method.

[regarding rustfmt.toml] is this necessary? it would be nice to know why...

removed it! I wanted to merge my imports in this module, forgot to remove it. Sorry!

I think we should probably move this stuff out of the fmt module and have botht he registry and fmt modules use it. Might be worth replacing the public API CurrentSpan type with this under the hood...

Agreed; a lot of this is just patching over the differences and attempting to get something working.

tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/sync.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
Copy link
Member Author

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry im like this!!!

tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/registry/sharded.rs Outdated Show resolved Hide resolved
Copy link
Member

@davidbarsky davidbarsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied most of your suggestions!

As for:

right, what I was getting at is that Registry::drop_span is only ever called by this method, why does there need to be a separate method? Why not just put the body of drop_span here?

gotcha! I mostly copying the structure of fmt as I familiarized myself with this codebase.

tracing-subscriber/src/fmt/fmt_layer.rs Outdated Show resolved Hide resolved
///
/// [`Layer`]: ../trait.Layer.html
#[derive(Debug)]
pub struct FmtLayer<
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be ideal if this was called fmt::Layer rather than fmt::Layer, so that it's more consistent with fmt::Subscriber...but then we would need to use the layer trait as layer::Layer...

N: for<'writer> FormatFields<'writer> + 'static,
W: MakeWriter + 'static,
{
/// Sets a [FormatEvent<S, N>].
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

link needs to be fixed — also i think the subscriber builder has a doc comment with examples for the equivalent method

// this needs to be a seperate impl block because we're re-assigning the the W2 (make_writer)
// type paramater from the default.
impl<S, N, E, W> Builder<S, N, E, W> {
/// Sets a [MakeWriter] for spans and events.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

link needs to be fixed, and can we copy the doc comment from the subscriber builder?

E: FormatEvent<S, N> + 'static,
W: MakeWriter + 'static,
{
/// Builds a [FmtLayer] infalliably.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

link needs to be fixed

}
}

impl<S> Default for Builder<S> {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's weird how impls on the layer and on the builder are interleaved here, can we sort them by type?

///
/// By storing [FormattedFields] instead of a [String] directly,
/// [FmtLayer] is able to be more defensive about other layers
/// accidentally a span's extensions.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these links need to be fixed...also, i think i left a comment on this earlier about a possible rewording? maybe it was lost in the move

N: for<'writer> FormatFields<'writer> + 'static,
{
/// Visits parent spans. Used to visit parent spans when formatting spans
/// and events
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, i think i left a comment on this that may have vanished?

let parents = span.parents().collect::<SpanRefVec<'_, _>>();
let mut iter = parents.iter().rev();
// visit all the parent spans...
while let Some(parent) = iter.next() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it might be more idiomatic to say

Suggested change
while let Some(parent) = iter.next() {
for parent in iter {

or even

Suggested change
while let Some(parent) = iter.next() {
for parent in parents.iter().rev() {

and get rid of the let iter =

// spans path. however, that requires passing the store to `visit_spans`
// with a different lifetime, and i'm too lazy to sort that out now. this
// workaround shouldn't remaining in the final shipping version _unless_
// benchmarks show that small-vector optimization is preferable to not-very-deep
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably remove the comment that says we shouldn't ship this, i think this implementation is probably fine (benches would still be good though)

tracing-subscriber/src/fmt/fmt_layer.rs Outdated Show resolved Hide resolved
tracing-subscriber/src/fmt/fmt_layer.rs Outdated Show resolved Hide resolved
W: MakeWriter + 'static,
{
/// Sets a [FormatEvent<S, N>].
pub fn with_event_formatter<E2>(self, e: E2) -> Builder<S, N, E2, W>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The equivalent method on SubscriberBuilder is just called

Suggested change
pub fn with_event_formatter<E2>(self, e: E2) -> Builder<S, N, E2, W>
pub fn fmt_event<E2>(self, e: E2) -> Builder<S, N, E2, W>

let's make these more consistent?

hawkw and others added 15 commits November 9, 2019 09:48
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@davidbarsky
Copy link
Member

Closed in favor of #420.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants