-
Notifications
You must be signed in to change notification settings - Fork 734
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
attributes: implement #[instrument(tracing)]
#1819
base: master
Are you sure you want to change the base?
Conversation
@@ -68,6 +70,17 @@ impl InstrumentArgs { | |||
} | |||
} | |||
|
|||
/// The location of the `tracing` crate. | |||
/// | |||
/// For backwards-compatibility, this must default to the plain `tracing` identifier with call site resolution. |
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'm not entirely sure if this should go into the doc comment, on second thought. A comment above the quote!(tracing)
may be more apt.
I'd actually like to suggest adding one of those breaking change comments there: A default of quote!(::tracing)
would avoid collisions with consumer-defined names just about entirely by default, but unfortunately it would also break the "hidden override" that's theoretically available right now.
d331d95
to
fabca1a
Compare
…ent the former This doesn't technically make the parameter more narrow, as the generated code would fail to compile with any other sort of path due to macro calls on it, but it maybe makes some error messages better.
#[instrument(tracing = ::tracing, level = 5)] | ||
pub fn level_5() {} | ||
#[instrument(tracing = ::tracing, level = 4)] | ||
pub fn level_4() {} | ||
#[instrument(tracing = ::tracing, level = 3)] | ||
pub fn level_3() {} | ||
#[instrument(tracing = ::tracing, level = 2)] | ||
pub fn level_2() {} | ||
#[instrument(tracing = ::tracing, level = 1)] | ||
pub fn level_1() {} | ||
|
||
const A_LEVEL: ::tracing::Level = ::tracing::Level::INFO; | ||
#[instrument(tracing = ::tracing, level = A_LEVEL)] | ||
pub fn level_ident() {} |
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 ability to specify the level through an integer constant or Level
-identifier seems to be undocumented, as far as the immediate ///
-documentation on #[instrument]
goes. Should I document it or is this deprecated/out of scope for this PR?
(I'd still like to keep these tests here regardless of the answer to that question, since they all have distinct code paths.)
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.
It should probably be documented, but in a follow-up PR. We should probably document it on the Level
type as well, since I believe its FromStr
implementation will also accept numbers.
I'll try to review this PR shortly, but looking over how you're generating components in Asteracea (to use let _guard = tracing::info_span!(#new_span_name).enter(); I still think it's probably a good idea for us to figure out the hygiene issues with the |
Thank you for the hint, I may eventually do that to keep the proc macro requirements low (or to work around the |
…o instead of using `#[instrument]` This skips waiting for <tokio-rs/tracing#1819> to land and should also compile a bit faster in some cases.
@Tamschi is this PR something you will continue working on, or should we close? |
Well I mean, I had completed this in January from my end. I was only waiting for a review. I can look into those conflicts though, one moment. |
There. This should be good to merge again, but if anything's amiss please let me know! |
Thanks for fixing the conflicts, we'll go through the code in the next few days. |
I just resolved the two merge conflicts that had appeared at some point since May, so this should be ready to merge again. (I wish there was a notification for this, that way I could have fixed it much earlier. Maybe I just missed it.) |
New year, new attempt 😅 Yes, I'm still (very slowly) building my framework on top of this branch. There is one clippy warning, but it's in a different crate untouched by this MR, so I didn't fix it on my end. |
any progress here? this is currently required for any crate that tries to reexport tracing (generated code trying to reexport everything under one crate, etc) |
# Conflicts: # tracing-attributes/src/expand.rs
I just resolved the new merge conflict (and a copy-paste mistake in an error message that I'd missed). But yeah, this would still be good to get merged. I've added support for coloured async to Asteracea since, and supporting tracing for that without relying on tracing-attributes would be cumbersome.
The implementation here has been complete for two and a half years, though I've had to fix merge conflicts occasionally. Maybe this fifth opportunity's a charm to get a review for it 😉 |
This adds an optional
tracing = Path
parameter to the#[instrument]
attribute, which can be used to override where the generated code looks for thetracing
crate. This defaults to justquote!(tracing)
, as before.Closes #1818.
Motivation
Please see the linked issue for details.
In short, this change makes
#[instrument]
more useful in proc macros (①¹) wheretracing
is available as optional dependency of the proc macro's library's main crate (②). With the override, ② can re-exporttracing
for use in ①'s output, which means library crates using ① via ② don't have to includetracing
as optional dependency/feature.¹ Sorry if this is odd. English isn't my first language and it's sometimes hard to use it unambiguously.
Solution
I tried to stay close to the style of the existing code.
So far, I've
target
,tracing
with#tracing
(and added the required
let tracing = args.tracing();
lookupwhere possible).To do:
add the lastargs.tracing()
lookup,Level
by ident for good measure,tracing::field::debug
(i.e. implicit field with non-Value
type),Debug
,Display
) forret
anderr
each andIt's getting late here and I have a question regarding an implementation detail (I'll comment about that in a moment), so I'm making a draft PR for now.