wgpu-core uses profiling for instrumentation, and fails to compile if a downstream crate enables the profile-with-tracing feature on a local profiling dependency.
Repro steps
cargo init wgpu-error
Add a wgpu-core = "0.8.1" dependency to Cargo.toml
Add a profiling = { version = "1.0.1", features = ["profile-with-tracing"] } dependency to Cargo.toml
cargo build
This results in a lengthy set of compiler errors, the most prominent of which is failed to resolve: use of undeclared crate or module 'tracing' on each invocation of the profiling::scope macro, and expected type parameter 'B', found struct 'profiling::tracing::level_filters::LevelFilter' where the macro is invoked in a generic context.
The other feature flags don't exhibit this issue. Adding a tracing dependency to the wgpu-error binary crate causes the same outcome, as does using version = "1" for profiling to match its entry in the wgpu-core Cargo.toml, so this doesn't appear to be a local dependency or version mismatch issue.
Given that the tracing dependency is present in profiling as a re-export, and that its presence in wgpu-error makes no difference, I suspect that $crate is actually resolving to the nonexistent wgpu-core::tracing due to some quirk with macro expansion.
aclysma
commented
3 years ago
wgpu-coreusesprofilingfor instrumentation, and fails to compile if a downstream crate enables theprofile-with-tracingfeature on a localprofilingdependency.Repro steps
cargo init wgpu-errorwgpu-core = "0.8.1"dependency toCargo.tomlprofiling = { version = "1.0.1", features = ["profile-with-tracing"] }dependency toCargo.tomlcargo buildThis results in a lengthy set of compiler errors, the most prominent of which is
failed to resolve: use of undeclared crate or module 'tracing'on each invocation of theprofiling::scopemacro, andexpected type parameter 'B', found struct 'profiling::tracing::level_filters::LevelFilter'where the macro is invoked in a generic context.The other feature flags don't exhibit this issue. Adding a tracing dependency to the
wgpu-errorbinary crate causes the same outcome, as does usingversion = "1"forprofilingto match its entry in the wgpu-core Cargo.toml, so this doesn't appear to be a local dependency or version mismatch issue.Given that the
tracingdependency is present inprofilingas a re-export, and that its presence inwgpu-errormakes no difference, I suspect that$crateis actually resolving to the nonexistentwgpu-core::tracingdue to some quirk with macro expansion.Relevant
wgpu-coreissue: https://github.com/gfx-rs/wgpu/issues/1477