Cannot build with tracing 0.1.39, when the crate name is core

[sxyazi]

Bug Report

Version

❯ cargo tree | grep tracing
└── tracing v0.1.39
    ├── tracing-attributes v0.1.27 (proc-macro)
    └── tracing-core v0.1.32
│   ├── tracing v0.1.39 (*)
│   ├── tracing v0.1.39 (*)
├── tracing v0.1.39 (*)
├── tracing-appender v0.2.2
│   └── tracing-subscriber v0.3.17
│       ├── tracing-core v0.1.32 (*)
│       └── tracing-log v0.1.3
│           └── tracing-core v0.1.32 (*)
├── tracing-subscriber v0.3.17 (*)

Platform

Darwin mac.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103 arm64

Crates

• tracing 0.1.39

Description

#2757 This PR introduces an issue where if the user's crate name is core, it will lead to a build error.

error[E0433]: failed to resolve: could not find `format_args` in `core`
  --> app/src/manager/folder.rs:15:4
   |
15 |             info!("{:?}", e);
   |             ^^^^^^^^^^^^^^^^ could not find `format_args` in `core`
   |
   = note: this error originates in the macro `$crate::event` which comes from the expansion of the macro`info` (in Nightly builds, run with -Z macro-backtrace for more info)

It typically occurs in projects that do not need to publish their crate to crates.io. See sxyazi/yazi#270 for more details.

[hawkw]

Ugh, that's quite unfortunate --- sorry this caused problems for you!

Ideally, tracing ought to be able to support both user code that redefines of the names of prelude macros, such as format_args! and concat! (which was the intent behind #2757 and #1842, and user-defined crates named core at the same time.

I think we could fix this by re-exporting all the prelude macros that the tracing macros use (in the #[doc_hidden] __macro_support module), and referencing them as $crate::__macro_support::concat!, $crate::__macro_support::format_args!, etc. This way, we would be using a fully-qualified path for these names, so they don't conflict with any user macros that shadow those names, but the fully-qualified path doesn't start with libcore, and thus shouldn't break when user code redefines core.

cc @kaffarell, do you think an approach like that would work?

[kaffarell]

Yes, I think that should work. Exported format_args, option::Option and iter::Iterator as well, so that we don't have any core::* stuff left. Will submit a PR now :)