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

Generated #[instrument] code is not qualified to the tracing crate #3119

Open
heaths opened this issue Oct 27, 2024 · 3 comments · May be fixed by #3126
Open

Generated #[instrument] code is not qualified to the tracing crate #3119

heaths opened this issue Oct 27, 2024 · 3 comments · May be fixed by #3126

Comments

@heaths
Copy link

heaths commented Oct 27, 2024

Bug Report

Version

  • tracing 0.1.40

Platform

Darwin Mac.localdomain 24.0.0 Darwin Kernel Version 24.0.0: Tue Sep 24 23:38:45 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T8122 arm64

Crates

tracing

Description

I created a tracing module in my crate to add a bunch of helpers for my use of the tracing crate. Probably not the best idea, but technical should work and naming is hard. I changed imports to use ::tracing::{instrument, Level} but then I was getting compiler errors like:

failed to resolve: could not find `span` in `tracing`
could not find `span` in `tracing`

failed to resolve: could not find `event` in `tracing`
could not find `event` in `tracing`

failed to resolve: could not find `Instrument` in `tracing`
could not find `Instrument` in `tracing`

lib.rs(9, 1): consider importing one of these traits: `use crate::instrument::Instrument;
`, `use ::tracing::Instrument;
`

If I rename my crate to something else - leaving the tracing crate import as either ::tracing or tracing, the generated code compiles fine. Perhaps the generated code should be emitting ::tracing as the prefix to avoid conflicts?

@Rustin170506
Copy link

Could you please provide a minimal reproducible Cargo project? That would help others reproduce the issue.

heaths added a commit to heaths/tracing that referenced this issue Oct 30, 2024
Avoid ambiguities with any user-defined `tracing` modules by globally qualifying types used in the attribute-generated code e.g., `::tracing::Level`.

Fixes: tokio-rs#3119
heaths added a commit to heaths/tracing that referenced this issue Oct 30, 2024
Avoid ambiguities with any user-defined `tracing` modules by globally qualifying types used in the attribute-generated code e.g., `::tracing::Level`.

Fixes: tokio-rs#3119
@heaths
Copy link
Author

heaths commented Oct 30, 2024

I opened 2 PRs: 1 each against master (v0.2.x?) and v0.1.x. We'd love to get at least a v0.1.28 of tracing-attributes. I can update this PR or submit another one if I should update any crates with a dependency on tracing-attributes e.g., tracing itself.

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

Successfully merging a pull request may close this issue.

2 participants