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

#[instrument] - support use of the 'self' variable in async-trait contexts #875

Merged
merged 5 commits into from
Aug 7, 2020
Merged

#[instrument] - support use of the 'self' variable in async-trait contexts #875

merged 5 commits into from
Aug 7, 2020

Conversation

nightmared
Copy link
Contributor

@nightmared nightmared commented Aug 2, 2020

Motivation

Fix #864.

Solution

Visit the fields and replace 'self' with '_self', and 'Self' with the type of the impl (when we can acces it, see #864 (comment) for current limitations).

@nightmared nightmared requested review from hawkw and a team as code owners August 2, 2020 09:30
@nightmared nightmared changed the title #[instrument] - support use of the 'self' variable with asyn-trait #[instrument] - support use of the 'self' variable in async-trait contexts Aug 2, 2020
@nightmared

This comment has been minimized.

@hawkw
Copy link
Member

hawkw commented Aug 3, 2020

The CI failure is not related to this change, sorry about that. We just merged PR #882 that should fix the CI failure. Mind rebasing onto master?

Copy link
Member

@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.

Overall, this looks pretty good — I had some style suggestions.

I wrote up a reply to your questions about handling Self types on functions without a self parameter here: #864 (comment). Let me know what you think?

@@ -211,20 +211,21 @@ pub fn instrument(
let input: ItemFn = syn::parse_macro_input!(item as ItemFn);
let args = syn::parse_macro_input!(args as InstrumentArgs);

let span_declared_name = input.sig.ident.to_string();
Copy link
Member

Choose a reason for hiding this comment

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

This naming is not super clear to me...also, this is the name of the instrumented function, and not necessarily the name of the span itself: it may be overridden with name = "something_else" in the macro's arguments.

Comment on lines 360 to 373
if let Some(async_trait_fun) = async_trait_fun {
if let Some(Fields(ref mut fields)) = args.fields {
for mut field in fields.iter_mut() {
if let Some(ref mut e) = field.value {
syn::visit_mut::visit_expr_mut(
&mut SelfReplacer {
ty: async_trait_fun.self_type.clone(),
},
e,
);
}
}
}
}
Copy link
Member

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: I think we can express this with a little less rightward drift, like this:

Suggested change
if let Some(async_trait_fun) = async_trait_fun {
if let Some(Fields(ref mut fields)) = args.fields {
for mut field in fields.iter_mut() {
if let Some(ref mut e) = field.value {
syn::visit_mut::visit_expr_mut(
&mut SelfReplacer {
ty: async_trait_fun.self_type.clone(),
},
e,
);
}
}
}
}
if let (Some(async_trait_fun), Some(Fields(ref mut fields))) = (async_trait_fun, args.fields) {
let mut replacer = SelfReplacer {
ty: async_trait_fun.self_type.clone(),
};
for e in fields.iter_mut().filter_map(|f| f.value.as_mut()) {
syn::visit_mut::visit_expr_mut(&mut replacer, e);
}
}

tracing-attributes/src/lib.rs Show resolved Hide resolved
Comment on lines +222 to +226
#[instrument(fields(Self=std::any::type_name::<Self>()))]
async fn call_with_self(&self) {}

#[instrument(fields(Self=std::any::type_name::<Self>()))]
async fn call_with_mut_self(self: &mut Self) {}
Copy link
Member

Choose a reason for hiding this comment

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

this is great, thanks for testing this.

@nightmared
Copy link
Contributor Author

nightmared commented Aug 4, 2020

Turns out I was wrong, it's not even possible (as far as I can tell) to obtain that information through a type alias, as there is no valid place where we can put the type alias: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5c0d0f71aa9d8fc0f18fa45d4987ff72 :/

Any other idea ? Otherwise we will be forced to accept that in some cases the user have to supply the Self type. Maybe we should document this shortcoming ?

@hawkw
Copy link
Member

hawkw commented Aug 4, 2020

Turns out I was wrong, it's not even possible (as far as I can tell) to obtain that information through a type alias, as there is no valid place where we can put the type alias: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5c0d0f71aa9d8fc0f18fa45d4987ff72 :/

Any other idea ? Otherwise we will be forced to accept that in some cases the user have to supply the Self type. Maybe we should document this shortcoming ?

Ugh, yeah, you're right...it looks like this may not be possible no matter what we do. Let's make sure that's documented. I don't think it's a terribly common case, at least.

Copy link
Member

@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.

This looks good to me. I had some minor documentation changes to suggest, but once those are addressed, I think this is good to merge.

Thanks!

tracing-attributes/src/lib.rs Outdated Show resolved Hide resolved
tracing-attributes/src/lib.rs Outdated Show resolved Hide resolved
tracing-attributes/src/lib.rs Outdated Show resolved Hide resolved
tracing-attributes/src/lib.rs Outdated Show resolved Hide resolved
tracing-attributes/src/lib.rs Outdated Show resolved Hide resolved
Several minor documentation edits.
Copy link
Member

@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.

I went ahead and fixed up the handful of small docs edits I commented on, and I'm going to merge this pending CI.

Thanks again for the fix! <3

@hawkw hawkw merged commit 9ae4676 into tokio-rs:master Aug 7, 2020
@nightmared
Copy link
Contributor Author

Nice ;)
Sorry for not fixing my tedious english when you suggested to, quite a few things dropped unexpectedly on my plate these last two days :/

@hawkw
Copy link
Member

hawkw commented Aug 7, 2020

Nice ;)
Sorry for not fixing my tedious english when you suggested to, quite a few things dropped unexpectedly on my plate these last two days :/

No problem at all!

hawkw added a commit that referenced this pull request Aug 10, 2020
Added

- Support for using `self` in field expressions when instrumenting
  `async-trait` functions (#875)
- Several documentation improvements (#832, #897, #911, #913)

Thanks to @anton-dutov and @nightmared for contributing to this release!
hawkw added a commit that referenced this pull request Aug 10, 2020
### Added

- Support for using `self` in field expressions when instrumenting
  `async-trait` functions (#875)
- Several documentation improvements (#832, #897, #911, #913)

Thanks to @anton-dutov and @nightmared for contributing to this release!
hawkw added a commit that referenced this pull request Aug 10, 2020
Fixed

- Updated `tracing-core` to fix incorrect calculation of the global max
  level filter (#908)

Added

- **attributes**: Support for using `self` in field expressions when
  instrumenting `async-trait` functions (#875)
- Several documentation improvements (#832, #881, #896, #897, #911,
  #913)

Thanks to @anton-dutov, @nightmared, @mystor, and @toshokan for
contributing to  this release!
hawkw added a commit that referenced this pull request Aug 11, 2020
### Fixed

- Updated `tracing-core` to fix incorrect calculation of the global max
  level filter (#908)

### Added

- **attributes**: Support for using `self` in field expressions when
  instrumenting `async-trait` functions (#875)
- Several documentation improvements (#832, #881, #896, #897, #911,
  #913)

Thanks to @anton-dutov, @nightmared, @mystor, and @toshokan for
contributing to  this release!

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
hawkw added a commit that referenced this pull request Aug 17, 2020
PR #875 added code to `tracing-attributes` that uses `Option::flatten`,
which was only added to the standard library in Rust 1.40. This broke
our MSRV, but we missed it because the MSRV CI checks weren't working
correctly (fixed in #934).

This commit removes the use of `Option::flatten`, and replaces it with a
manual implementation. It's a little less pretty, but it builds on our
MSRV (1.39.0).
@hawkw hawkw mentioned this pull request Aug 17, 2020
hawkw added a commit that referenced this pull request Aug 17, 2020
PR #875 added code to `tracing-attributes` that uses `Option::flatten`,
which was only added to the standard library in Rust 1.40. This broke
our MSRV, but we missed it because the MSRV CI checks weren't working
correctly (fixed in #934).

This commit removes the use of `Option::flatten`, and replaces it with a
manual implementation. It's a little less pretty, but it builds on our
MSRV (1.39.0).
@nightmared nightmared deleted the self-instrument-fields branch December 30, 2020 13:35
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.

#[instrument] - must refer to _self instead of self when instrumenting an async-trait instance method
2 participants