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

tracing-attributes 0.1.14 causes variables to be out of scope when they're in scope #1296

Closed
jeromegn opened this issue Mar 11, 2021 · 7 comments · Fixed by #1297
Closed
Labels
crate/attributes Related to the `tracing-attributes` crate kind/bug Something isn't working

Comments

@jeromegn
Copy link
Contributor

Bug Report

Version

│   │   └── tracing v0.1.25
│   │       ├── tracing-attributes v0.1.14 (proc-macro)
│   │       └── tracing-core v0.1.17
│   ├── tracing v0.1.25 (*)
│   └── tracing v0.1.25 (*)
│   └── tracing v0.1.25 (*)
├── tracing v0.1.25 (*)
├── tracing-core v0.1.17 (*)
├── tracing-futures v0.2.5
│   └── tracing v0.1.25 (*)
├── tracing-log v0.1.2
│   └── tracing-core v0.1.17 (*)
├── tracing-subscriber v0.2.16
│   ├── tracing v0.1.25 (*)
│   ├── tracing-core v0.1.17 (*)
│   ├── tracing-log v0.1.2 (*)
│   └── tracing-serde v0.1.2
│       └── tracing-core v0.1.17 (*)

Platform

Darwin Kernel Version 20.3.0 (AMR64)

Crates

tracing-attributes

Description

Upgrading to tracing-attributes 0.1.14 appears to be placing variables out of scope.

I don't exactly have a minimal reproduction, but here's roughly the code that causes it:

#[instrument(skip(self, req), fields(app_id))]
fn call(&mut self, req: (Req, IpAddr)) -> Self::Future {
    // ...
    let metrics = self.metrics.clone();
    // ...
    Box::pin(async move {
        // ...
        metrics // cannot find value `metrics` in this scope
    })
}

Removing #[instrument(...)] fixes the issue.

@hawkw
Copy link
Member

hawkw commented Mar 11, 2021

cc @nightmared, it looks like this may have been introduced in #1228?

I'll take a look soon.

@hawkw hawkw added crate/attributes Related to the `tracing-attributes` crate kind/bug Something isn't working labels Mar 11, 2021
@nightmared
Copy link
Contributor

Hmm yes, I can reproduce this:

impl TestImpl {
        #[instrument]
        fn fun(&self) -> Pin<Box<dyn std::future::Future<Output = ()> + Send>> {
            let val = self.clone();
            Box::pin(async move {
                println!("{:?}", val);
            })
        }
    }

yields

    impl TestImpl {
        fn fun(&self) -> Pin<Box<dyn std::future::Future<Output = ()> + Send>> {
            Box::pin(async move {
                let __tracing_attr_span = {
                    use ::tracing::__macro_support::{Callsite as _, Registration};
                    static CALLSITE: ::tracing::__macro_support::MacroCallsite = {
                        use ::tracing::__macro_support::{MacroCallsite, Registration};
                        static META: ::tracing::Metadata<'static> = {
                            ::tracing_core::metadata::Metadata::new(
                                "fun",
                                "async_fn",
                                tracing::Level::INFO,
                                Some("tracing-attributes/tests/async_fn.rs"),
                                Some(220u32),
                                Some("async_fn"),
                                ::tracing_core::field::FieldSet::new(
                                    &["self"],
                                    ::tracing_core::callsite::Identifier(&CALLSITE),
                                ),
                                ::tracing::metadata::Kind::SPAN,
                            )
                        };
                        static REG: Registration = Registration::new(&CALLSITE);
                        MacroCallsite::new(&META, &REG)
                    };
                    let mut interest = ::tracing::collect::Interest::never();
                    if tracing::Level::INFO <= ::tracing::level_filters::STATIC_MAX_LEVEL
                        && tracing::Level::INFO <= ::tracing::level_filters::LevelFilter::current()
                        && {
                            interest = CALLSITE.interest();
                            !interest.is_never()
                        }
                        && CALLSITE.is_enabled(interest)
                    {
                        let meta = CALLSITE.metadata();
                        ::tracing::Span::new(meta, &{
                            #[allow(unused_imports)]
                            use ::tracing::field::{debug, display, Value};
                            let mut iter = meta.fields().iter();
                            meta.fields().value_set(&[(
                                &iter.next().expect("FieldSet corrupted (this is a bug)"),
                                Some(&tracing::field::debug(&self) as &Value),
                            )])
                        })
                    } else {
                        let span = CALLSITE.disabled_span();
                        {};
                        span
                    }
                };
                tracing::Instrument::instrument(
                    async move {
                        {
                            {
                                ::std::io::_print(::core::fmt::Arguments::new_v1(
                                    &["", "\n"],
                                    &match (&val,) {
                                        (arg0,) => [::core::fmt::ArgumentV1::new(
                                            arg0,
                                            ::core::fmt::Debug::fmt,
                                        )],
                                    },
                                ));
                            };
                        }
                    },
                    __tracing_attr_span,
                )
                .await
            })
        }
    }

I will take a look

@nightmared
Copy link
Contributor

Oh wait, that looks like a stupid one-line mistake I made

@hawkw
Copy link
Member

hawkw commented Mar 11, 2021

FWIW, I just wrote a test in a branch, I can push that up if you like?

hawkw added a commit that referenced this issue Mar 11, 2021
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@nightmared
Copy link
Contributor

Yeah, I think I'm going to open a PR with a new test and the code to fix that mistake

@hawkw
Copy link
Member

hawkw commented Mar 11, 2021

@nightmared please feel free to use the test in this branch if you like: https://github.com/tokio-rs/tracing/tree/eliza/attributes-1296

@hawkw
Copy link
Member

hawkw commented Mar 11, 2021

In general, it seems like, while we have plenty of tests for instrumenting async fn and async_trait fns, we could use more tests for instrumenting synchronous functions returning Box::pinned futures?

(but, let's focus on solving this specific problem first 🙂)

nightmared added a commit to nightmared/tracing that referenced this issue Mar 11, 2021
nightmared added a commit to nightmared/tracing that referenced this issue Mar 11, 2021
hawkw pushed a commit that referenced this issue Mar 11, 2021
…utures (#1297)

Fixes #1296.

I had forgotten to use all the input statements in #1228, so we would
delete nearly all the statement of sync functions that return a boxed
future :/
hawkw pushed a commit that referenced this issue Mar 12, 2021
…utures (#1297)

This backports #1297 from `master`.

Fixes #1296.

I had forgotten to use all the input statements in #1228, so we would
delete nearly all the statement of sync functions that return a boxed
future :/
hawkw pushed a commit that referenced this issue Mar 12, 2021
…utures (#1297)

This backports #1297 from `master`.

Fixes #1296.

I had forgotten to use all the input statements in #1228, so we would
delete nearly all the statement of sync functions that return a boxed
future :/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate/attributes Related to the `tracing-attributes` crate kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants