tracing: Add span- and event-specific enabled! variants
#1892
Labels
Comments
hawkw
added
kind/feature
|
cc @guswynn |
hawkw
added a commit
that referenced
this issue
Mar 31, 2022
## Motivation Closes #1892 ## Solution This branch adds new `span_enabled!` and `event_enabled!` macros. I went withe sharing as much of the macro as possible. The new macros were implemented by adding a `kind:` parameter to `enabled!`, and invoking `enabled!` with the appropriate `kind:` argument. This means in the docs, the macro only shows the `($($rest:tt)*)=> (...)` variant, but I think linking to the `enabled!` docs should be fine. Also, I find the macro pattern part of rustdoc to be very hard to understand, and I think many people dont look at it. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this issue
Apr 1, 2022
## Motivation Closes #1892 ## Solution This branch adds new `span_enabled!` and `event_enabled!` macros. I went withe sharing as much of the macro as possible. The new macros were implemented by adding a `kind:` parameter to `enabled!`, and invoking `enabled!` with the appropriate `kind:` argument. This means in the docs, the macro only shows the `($($rest:tt)*)=> (...)` variant, but I think linking to the `enabled!` docs should be fine. Also, I find the macro pattern part of rustdoc to be very hard to understand, and I think many people dont look at it. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this issue
Apr 1, 2022
## Motivation Closes #1892 ## Solution This branch adds new `span_enabled!` and `event_enabled!` macros. I went withe sharing as much of the macro as possible. The new macros were implemented by adding a `kind:` parameter to `enabled!`, and invoking `enabled!` with the appropriate `kind:` argument. This means in the docs, the macro only shows the `($($rest:tt)*)=> (...)` variant, but I think linking to the `enabled!` docs should be fine. Also, I find the macro pattern part of rustdoc to be very hard to understand, and I think many people dont look at it. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this issue
Apr 1, 2022
## Motivation Closes #1892 ## Solution This branch adds new `span_enabled!` and `event_enabled!` macros. I went withe sharing as much of the macro as possible. The new macros were implemented by adding a `kind:` parameter to `enabled!`, and invoking `enabled!` with the appropriate `kind:` argument. This means in the docs, the macro only shows the `($($rest:tt)*)=> (...)` variant, but I think linking to the `enabled!` docs should be fine. Also, I find the macro pattern part of rustdoc to be very hard to understand, and I think many people dont look at it. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this issue
Apr 1, 2022
## Motivation Closes #1892 ## Solution This branch adds new `span_enabled!` and `event_enabled!` macros. I went withe sharing as much of the macro as possible. The new macros were implemented by adding a `kind:` parameter to `enabled!`, and invoking `enabled!` with the appropriate `kind:` argument. This means in the docs, the macro only shows the `($($rest:tt)*)=> (...)` variant, but I think linking to the `enabled!` docs should be fine. Also, I find the macro pattern part of rustdoc to be very hard to understand, and I think many people dont look at it. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
hawkw
added a commit
that referenced
this issue
Apr 1, 2022
## Motivation Closes #1892 ## Solution This branch adds new `span_enabled!` and `event_enabled!` macros. I went withe sharing as much of the macro as possible. The new macros were implemented by adding a `kind:` parameter to `enabled!`, and invoking `enabled!` with the appropriate `kind:` argument. This means in the docs, the macro only shows the `($($rest:tt)*)=> (...)` variant, but I think linking to the `enabled!` docs should be fine. Also, I find the macro pattern part of rustdoc to be very hard to understand, and I think many people dont look at it. Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Feature Request
Crates
tracingMotivation
Currently, the callsites constructed by the
enabled!macro count as neither spans nor events, so that they are not effected by filtering configurations that specifically enable spans or specifically enable events. This reduces false positives. In some situations, though, a user may wish to check specifically if a span would be enabled, or if an event would be enabled. See #1821 (comment) for details.Proposal
PR #1891 makes a change in
tracing-coreto allow constructing callsite kinds that are spans/events and hints at the same time. This can be used to add support for checking if specific kinds of callsite would be enabled.We should add new
span_enabled!andevent_enabled!macros that use this API. These macros would behave likeenabled!but would createSPAN | HINTandEVENT | HINTcallsites, respectively.Alternatives
Alternatively, we could add this to the existing
enabled!macro, likeenabled!(span, ...)andenabled!(event, ...). IMO, just making separate macros is a bit more obvious from a UX perspective, but I'm open to being convinced otherwise.The text was updated successfully, but these errors were encountered: