wgpu-core compile failure with profile-with-tracing profiling feature

[Shfty]

Description
wgpu-core fails to compile if a downstream crate includes a profiling dependency with the profile-with-tracing feature enabled.

This issue doesn't occur when using the the profile-with-puffin, profile-with-optick, profile-with-superluminal or profile-with-tracy feature flags.

Repro steps

• Create a new binary crate
• Add a wgpu-core = "0.8.1" dependency
• Add a profiling = { version = "1.0.1", features = ["profile-with-tracing"] } dependency
• cargo build

Adding a tracing = "0.1.26" dependency causes the same outcome, as does using version = "1" for profiling to match its entry in the wgpu-core Cargo.toml.

Expected vs observed behavior
Expected:
wgpu-core compiles successfully, and the profiling macros therein emit tracing spans that can be captured by the calling program.

In this case, my intent is to capture wgpu-core spans as part of the instrumentation data for an async program.
The functions calling wgpu will be instrumented using tracing wrappers, with a view to displaying wgpu-core spans (and wgpu log messages converted into tracing events) as their children inside a debug / profiling UI.

Observed:
Various wgpu-core invocations of profiling macros throw use of undeclared crate or module 'tracing' errors, followed by a further set of expected type parameter 'B', found struct 'profiling::tracing::level_filters::LevelFilter' errors.

Platform
Windows 10 64-bit
stable-x86_64-pc-windows-msvc
rustc 1.52.1
wgpu-core 0.8.1
profiling 1.0.1

[Shfty]

As an aside, the Logging section of the crates.io page for wgpu notes that wgpu-core uses tracing for logging. This should be updated to reflect the switch to profiling.

[Uriopass]

I think this should be posted to profiling's repo, as IMHO any program using profiling shouldn't fail to compile regardless of the enabled feature.
They should also understand why it happens better, and it would help other users of profiling :).

[Shfty]

That's reasonable - I considered it before posting here, but figured it would be better to see if there was any insight to be gained from the downstream crate first.

Their docs seem pretty cut and dry about library use-cases behaving transparently, so I'll write up an issue over there in a bit.

[aclysma]

profiling 1.0.2 should fix this

[cwfitzgerald]

That's great to hear, thank you!

[Shfty]

Working as expected, thanks!

(Disregard any unexpected ordering - that's probably my fault.)