-
Notifications
You must be signed in to change notification settings - Fork 722
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
fix: prefix macro calls with ::core to avoid clashing with local macros #3024
fix: prefix macro calls with ::core to avoid clashing with local macros #3024
Conversation
This commit fixes a bug where a macro call to macros defined in the standard lib from the `tracing` and `tracing-core` crates could be resolved to a local macro with the same name, causing a compilation error. This commit prefixes these calls with `::core::` to ensure that they are resolved to the standard library macros. Fixes: <tokio-rs#3023>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ensures that the tracing lib correctly builds when a crate is named `core`. See tokio-rs#2761 and tokio-rs#2762 for more info.
Wow, that's an interesting problem -
Addressed in 5960e0a by adding these to the __macro_support in tracing / tracing_core. I didn't change all the occurrences of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
ping |
Can this also be backported to the 0.1 branch please? (Happy to add another PR for that if needed) |
Motivation
This commit fixes a bug where a macro call to macros defined in the
standard lib from the
tracing
andtracing-core
crates could beresolved to a local macro with the same name, causing a compilation
error.
Solution
This commit prefixes these calls with
::core::
to ensure thatthey are resolved to the standard library macros.
Fixes: #3023
While this fixes the specific issue at hand, there's likely many macro calls that are impacted by this problem - specifically every call to module_path (there are many). I haven't updated all of those places as I was unsure if that was a good idea as there's about 220 calls of that macro. I also haven't checked for other macros that would also be problematic.