don't pull attributes feature of tracing

[matklad]

cc tokio-rs/tracing#1526

[matklad]

would appreciate a release with this one

[hawkw]

AFAICT, this crate really doesn't need to depend on tracing at all; as a Layer implementation, it should only need to depend on tracing_core and tracing_subscriber. The difference between depending on tracing and tracing_core is that tracing includes the instrumentation-side API (e.g., the macros, the Span type, and other APIs for emitting trace data), which this crate doesn't use at all (except in examples).

I think the best thing is probably to just replace the tracing dependency with tracing_core here.

[matklad]

(CI failure is unrelated)

@hawkw good suggestion! One interesting observation here is that tracing_subscriber itself depends on tracing when filter features is enabled, which again means that all actual subscribers are compield after syn (if the attributes feature is enaled). Naively, I'd expect STATIC_MAX_LEVEL to live in tracing_core, and for tracing_subscriber to not depend on tracing.

[hawkw]

Hmm, the filter feature should probably not be enabled by crates that provide subscriber implementations.

In the future, we should probably split out the implementations (e.g. env_filter) from the core traits in tracing_subscriber, and put the core tracing-subscriber traits in a separate downstream crate...

[matklad]

Hmm, the filter feature should probably not be enabled by crates that provide subscriber implementations.

In my case, it’s the leaf crate that enables the filter feature, but that still means that the subscriber gets this feature, and needs to be compiled after proc macros.

[davidbarsky]

Whoops, sorry, I didn't see this PR. I'll fixup the CI issues, but I'm happy to merge this after.

[davidbarsky]

@matklad Took me a second, sorry! Now that #34 is merged, do you think you can rebase against the main branch? I'll be happy to merge this in after and do a release.