Both tracing and tracing-subscriber depend on tracing-core with default-features = false. However, tracing-subscriber also depends on tracing-log (optionally, by but enabled by default), which depends on tracing-core with default features. So, building a crate (or workspace) that contains tracing-subscriber, without additional tuning, will build tracing-core with default features, even though both tracing-core and tracing-subscriber say they depend on tracing-core without default features.
One subtlety is that in a workspace, if a package is selected (-p/--package) that only depends on tracing-core, they will be built without tracing-core's default features. Consequently, cargo sees a different feature set, and considers it a different "kind" of build, which may be unexpected; e.g. the mangled symbol names will have a different hash suffix (as per the current, "legacy" mangling scheme).
More concretely, one can observe that after building the whole workspace, building the specific package (that only depends on tracing core) isn't a "no-op", since it has a different feature set. Arguably, such a build is unnecessary.
For me, the different feature set and subsequent hashes caused problems when generating and inspecting LLVM IR for a specific crate in a package; of course, I expect the number of other users who have been impacted by the above described edge case minimal.
Also, I'm not 100% sure, but this may create problems for users who transitively depended on tracing-core with default features, without explicitly stating it, since now tracing-core will be included without default features (I don't recall if Rust/cargo lets you use crates that haven't been explicitly named. I think it would be possible with an extern crate definition.)
Solution
Set default-features = false for tracing-core dependency in tracing-log, tracing-journald, and tracing-futures.
Motivation
Both tracing and tracing-subscriber depend on tracing-core with default-features = false. However, tracing-subscriber also depends on tracing-log (optionally, by but enabled by default), which depends on tracing-core with default features. So, building a crate (or workspace) that contains tracing-subscriber, without additional tuning, will build tracing-core with default features, even though both tracing-core and tracing-subscriber say they depend on tracing-core without default features.
One subtlety is that in a workspace, if a package is selected (-p/--package) that only depends on tracing-core, they will be built without tracing-core's default features. Consequently, cargo sees a different feature set, and considers it a different "kind" of build, which may be unexpected; e.g. the mangled symbol names will have a different hash suffix (as per the current, "legacy" mangling scheme).
More concretely, one can observe that after building the whole workspace, building the specific package (that only depends on tracing core) isn't a "no-op", since it has a different feature set. Arguably, such a build is unnecessary.
For me, the different feature set and subsequent hashes caused problems when generating and inspecting LLVM IR for a specific crate in a package; of course, I expect the number of other users who have been impacted by the above described edge case minimal.
Also, I'm not 100% sure, but this may create problems for users who transitively depended on tracing-core with default features, without explicitly stating it, since now tracing-core will be included without default features (I don't recall if Rust/cargo lets you use crates that haven't been explicitly named. I think it would be possible with an
extern cratedefinition.)Solution
Set
default-features = falsefor tracing-core dependency in tracing-log, tracing-journald, and tracing-futures.