-
Notifications
You must be signed in to change notification settings - Fork 741
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
Allow skipping arguments in #[instrument]
.
#359
Conversation
This adds a `skip` directive to the `#[instrument]` macro that allows specifying one or more arguments to the function which will not appear in the generated span. In particular, this means that it's possible to use `#[instrument]` on functions with a non-`Debug` parameter.
tracing-attributes/src/lib.rs
Outdated
lit.span() => compile_error!("expected only a single `skip` argument!") | ||
}; | ||
*/ | ||
panic!("not sure how to make this return an error -- the examples below return impl ToTokens and get stuck into the output."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be fixed before merging but I'm not sure what the appropriate way to return an error in a proc macro is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commented-out code above is correct with regards to how you'd display the error to the user — you want to return a quote
ed block that expands to the compile_error!
macro.
However, unlike the other functions that return impl ToTokens
, this function isn't actually returning anything that expands to tokens; it's returning a HashSet
. I'd probably make this return a Result<HashSet<Ident>, impl ToTokens>
or something? Then, at the call site, you could match the result and insert the compiler error if it's an Err
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hdevalence this is great, thanks so much!
I'd be very happy to merge this once the error handling thing is resolved --- I tried to answer your question in my review. I also commented on a couple of nits that aren't really blockers.
tracing-attributes/src/lib.rs
Outdated
lit.span() => compile_error!("expected only a single `skip` argument!") | ||
}; | ||
*/ | ||
panic!("not sure how to make this return an error -- the examples below return impl ToTokens and get stuck into the output."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commented-out code above is correct with regards to how you'd display the error to the user — you want to return a quote
ed block that expands to the compile_error!
macro.
However, unlike the other functions that return impl ToTokens
, this function isn't actually returning anything that expands to tokens; it's returning a HashSet
. I'd probably make this return a Result<HashSet<Ident>, impl ToTokens>
or something? Then, at the call site, you could match the result and insert the compiler error if it's an Err
.
@@ -80,8 +82,8 @@ fn fields() { | |||
.run_with_handle(); | |||
|
|||
with_default(subscriber, || { | |||
my_fn(2, false); | |||
my_fn(3, true); | |||
my_fn(2, false, UnDebug(0), UnDebug(1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we also add a .only()
to the mock fields above, so that we assert no other fields are also added to the generated span? like:
span.clone().with_field(
field::mock("arg1")
.with_value(&format_args!("2"))
.and(field::mock("arg2").with_value(&format_args!("false")))
.only(),
),
fn my_fn(arg1: usize, arg2: bool) {} | ||
struct UnDebug(pub u32); | ||
|
||
#[instrument(target = "my_target", level = "debug", skip(_arg3, _arg4))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Take it or leave it, but: rather than adding the skip
behavior to this test, I might add a new test for the skip
attribute? That way, if there's a regression that breaks only the skip
attribute, we could see what behavior is broken based on which test fails. Not a blocker though!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be happy to add a new test, but I didn't do it mostly because I don't really understand how the span and subscriber mocking works, so adding into the existing test seemed easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple minor nits if you're interested in addressing them as well. Otherwise, this looks great, thanks!
Co-Authored-By: Eliza Weisman <[email protected]>
@hdevalence I think the CI build for this is failing because |
Fixed! |
Hmm, I ran |
Oh, maybe it was that I ran |
And merged! Thanks @hdevalence! |
Added: - Optional `skip` argument to `#[instrument]` for excluding function parameters from generated spans (#359) Signed-off-by: Eliza Weisman <[email protected]>
Added: - Optional `skip` argument to `#[instrument]` for excluding function parameters from generated spans (#359) Signed-off-by: Eliza Weisman <[email protected]>
Added: - Optional `skip` argument to `#[instrument]` for excluding function parameters from generated spans (#359) Signed-off-by: Eliza Weisman <[email protected]>
Added: - Optional `skip` argument to `#[instrument]` for excluding function parameters from generated spans (#359) Signed-off-by: Eliza Weisman <[email protected]>
Added: - Optional `skip` argument to `#[instrument]` for excluding function parameters from generated spans (#359) Signed-off-by: Eliza Weisman <[email protected]>
@hdevalence just wanted to let you know that this has now been published in |
Thanks! |
Added - Support for destructuring in arguments to `#[instrument]`ed functions (#397) - Generated field for `self` parameters when `#[instrument]`ing methods (#397) - Optional `skip` argument to `#[instrument]` for excluding function parametersfrom generated spans (#359) - Added `dispatcher::set_default` and `subscriber::set_default` APIs, which return a drop guard (#388) Fixed - Some minor documentation errors (#356, #370) Signed-off-by: Eliza Weisman <[email protected]>
* tracing: bump attrs and core versions Signed-off-by: Eliza Weisman <[email protected]> * tracing: prepare to release 0.1.10 Added - Support for destructuring in arguments to `#[instrument]`ed functions (#397) - Generated field for `self` parameters when `#[instrument]`ing methods (#397) - Optional `skip` argument to `#[instrument]` for excluding function parametersfrom generated spans (#359) - Added `dispatcher::set_default` and `subscriber::set_default` APIs, which return a drop guard (#388) Fixed - Some minor documentation errors (#356, #370) Signed-off-by: Eliza Weisman <[email protected]>
Motivation
This adds a
skip
directive to the#[instrument]
macro that allowsspecifying one or more arguments to the function which will not appear
in the generated span. In particular, this means that it's possible to
use
#[instrument]
on functions with a non-Debug
parameter.Solution
The interior of a
skip(arg1, arg2)
argument is scanned for identifiers and these are filtered out of the identifier list used to generate the span.This hopefully closes #11.