Reexporting `instrument` macro searches for tracing as root dependency

[gheorghitamutu]

Bug Report

Version

tracing = { version = "0.1.41", default-features = true }

Platform

UNIX

Crates

tracing-attributes / tracing

Description

Reexporting tracing from another crate/lib as

pub mod tracing {
    pub use tracing::*;
}

and using it in another crate as

#[tracing::instrument(err)]
fn fn_test() -> Result<Self> {
  Ok(())
}

results in

error[E0433]: failed to resolve: could not find `instrument` in `tracing`
  --> <line>
   |
68 |     #[tracing::instrument(err)]
   |                ^^^^^^^^^^ could not find `instrument` in `tracing`

that can't be fixed unless I'm importing the tracing library into the new module.
That defeats the purpose of reexporting.

A similar issue serde solved here with some custom code. Is there an option to do the same for tracing?

[hmacias-avaya]

having a similar issue here. I was able to use this in prior versions of tracing; now after doing a "cargo update" I'm no longer able to do this.

[jplatte]

Quoting @hds (#3126 (comment))

I think the problem here is that we can either support users having some module called tracing in the current scope that isn't the real tracing or we can support users only importing tracing via a re-export of the whole crate which brings the real tracing into scope as a module.

However, I don't believe that we can support both cases at the same time. If you know a way, please let me know.

I appreciate that this is a breaking change for you, and I don't want to downplay that, but we're really considering the previous behavior of not using an absolute path as a defect that should be fixed and how the macro should have been implemented all along.

[hds]

Does this work for you? from #3126 by @jplatte:

use lib::tracing::*;
extern crate self as tracing;

[jplatte]

(note that the above would have to be put in the crate root of the crate that wants to use a re-exported tracing::instrument)

[hmacias-avaya]

thanks @hds and @jplatte. This seems to work for me.

[gheorghitamutu]

Thank you a lot, guys!
It works.

[Veetaha]

For anyone who landed on this issue when trying to upgrade tracing. We have hundreds of crates that use a reexported tracing::instrument macro, so we had to update hundreds of manifest files to add the explicit tracing dependency to them.

I created this small nushell script that uses rg (ripgreg) and updates all Cargo.toml files for crates that have signs of instrument macro usage in any directory of the repo recursively:

#!/usr/bin/env nu

# Identifies crates that use the `instrument` macro by scanning their source files for this pattern
let instrument_regex = '#\[.*instrument.*'

(
    ls ./**/Cargo.toml
    | get name
    | each {|manifest_path|
        let manifest = open $manifest_path
        if 'dependencies' not-in $manifest {
            return
        }
        let package_dir = ($manifest_path | path parse).parent
        let src = $"($package_dir)/src"

        let match_result = (
            ^rg --json $instrument_regex $src
            | lines
            | each {|| from json }
            | filter {|| 'stats' in $in.data }
            | first
        )

        let total_instruments = $match_result.data.stats.matched_lines

        print --stderr $"($package_dir): ($total_instruments) instruments"

        if $total_instruments == 0 {
            return
        }

        let manifest_source = $manifest_path | open --raw

        (
            $manifest_source
            | str replace '[dependencies]' "[dependencies]\ntracing = { workspace = true }"
            | save -f $manifest_path
        )
    }
)

After you run this script you might also want to format all your manifests with taplo fmt

---

You may also see some "unused method" warnings since the new version of tracing-attributes seems to generate some code that now enables rustc to detect the methods annotated with #[instrument] as unused