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

implementation specific names are un-hygenically leaked into user code in the event! macro (& friends) #2332

Open
iitalics opened this issue Oct 1, 2022 · 3 comments

Comments

@iitalics
Copy link

iitalics commented Oct 1, 2022

Bug Report

Version

$ cargo tree | grep tracing
├── tracing v0.1.36
│ ├── tracing-attributes v0.1.22 (proc-macro)
│ └── tracing-core v0.1.29
└── tracing-subscriber v0.3.15
├── tracing-core v0.1.29 ()
└── tracing-log v0.1.3
└── tracing-core v0.1.29 (
)

Description

within the event! macro, some identifiers such as display, are un-hygienically leaked into the user's format arguments, which causes them to shadow local variables.

example:

use tracing::event;

fn main() {
    let display = "foo";
    let s = event!(tracing::Level::INFO, "length: {}", display.len());
}

i expect this to log length: 3, but instead i get this error:

error[E0599]: no method named `len` found for fn item `fn(_) -> DisplayValue<_> {display::<_>}` in the current scope
 --> src/main.rs:5:64
  |
5 |     let s = event!(tracing::Level::INFO, "length: {}", display.len());
  |                                                        ------- ^^^ method not found in `fn(_) -> DisplayValue<_> {display::<_>}`
  |                                                        |
  |                                                        this is a function, perhaps you wish to call it

to be honest i thought that rust's hygene in macro_rules! would have prevented this class of error but apparently it is still a problem

@hawkw
Copy link
Member

hawkw commented Oct 2, 2022

This is, unfortunately, a known issue (see #805 and, more recently, #2278), which we can't fix without a breaking change. We "fixed" it two years ago in #806, but unfortunately had to revert that change (2feb61d) when it turned out existing code was actually relying on those names being imported (#820).

Sorry! I hate this too, but here we are. :(

@yshui
Copy link

yshui commented Nov 8, 2022

I hit this problem too. Can we fix this with a non-backward compatible version number bump?

@davidbarsky
Copy link
Member

this can be fixed in tracing 0.2, yes.

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

No branches or pull requests

4 participants