-
Notifications
You must be signed in to change notification settings - Fork 749
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
macros use fields more than once #1739
Comments
Yeah, this has --- unfortunately --- been a known issue for quite a while now (see #196). I'd really, really like to fix this, but I wasn't able to find a good solution last time I spent time looking into this. If you're interested in helping out, a fresh pair of eyes could be useful! I'm happy to answer any questions if you do take a look at it. |
Staring at this I agree it's a pain. My only thought at the moment would be to use the |
This cheanges the event macro (and all the upstream macros like info!), so that it only uses each field once when the log feature is enabled. Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. This change generates the log using the `ValueSet` meaning the token trees are only substituted once. Fixes: tokio-rs#196, tokio-rs#1739
This changes the event macro (and all the upstream macros like info!), so that it only uses each field once when the log feature is enabled. Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. This change generates the log using the `ValueSet` meaning the token trees are only substituted once. Fixes: tokio-rs#196, tokio-rs#1739
## Motivation Fixes: #196, #1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
## Motivation Fixes: #196, #1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
## Motivation Fixes: #196, #1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
## Motivation Fixes: #196, #1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
## Motivation Fixes: #196, #1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
## Motivation Fixes: #196, #1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
## Motivation Fixes: tokio-rs#196, tokio-rs#1739 Previously, the `field` token trees would be substituted into the log macro invocation and the `ValueSet`, potentially meaning they are executed more than once. ## Solution This changes the `event!` macro (and all the upstream macros like `info!`), so that it only uses each field once when the log feature is enabled. It does this by generating the log using the `ValueSet` meaning the token trees are only substituted once.
Bug Report
Some tracing macros can use the fields provided more than once causing confusing and non-local error messages.
Version
Discovered on
0.1.29
, from a code read also looks to be present onmaster
.Crates
tracing
Description
when the above code is compiled with the
log
feature enabled, you get the following compiler error:(You can also extend this to weird and wonderful effects, such as a counter that depends on the feature flags and log level.)
This error is confusing by itself, but is made worse by the fact that it can be triggered indirectly; this (A) compiles fine without the log feature enabled, but if a crate (B) depends on A and (even indirectly) enables the log feature then A will fail to compile as part of B, but will compile fine by itself.
From a quick code read I think there may be other macros affected by this, but I haven't investigated any further.
The text was updated successfully, but these errors were encountered: