Switch from lazy_static to once_cell

[jplatte]

It would be nice if tracing could switch from lazy_static to once_cell like tokio did. I don't think there are any downsides, and it reduces the number of dependencies for crates that depend on both tracing and tokio (for example through hyper).

Crates

• tracing-core

Motivation

Fewer dependencies, less work to later switch to std's Lazy type if / when it is stabilized.

Proposal

Replace usage of lazy_static! with once_cell::sync::Lazy.

Alternatives

Do nothing. That would mean lots of applications have two crates that do the same thing in their dependency tree (though they're not big, so it's not that bad).

[taiki-e]

This also allows removing some vendored code (#424).

EDIT: #1165 (comment)

[hawkw]

I'm fine with this. I've been conservative about switching away from lazy_static due to stability, but it seems once_cell has been 1.0 for a while.

This also allows removing some vendored code (#424).

I don't think this is correct, though. The vendored code is the no_std version of lazy_static using a spinlock. We're vendoring it because it's not possible to conditionally enable a feature flag of a dependency when tracing's "std" feature is disabled, only to disable feature flags. once_cell, AFAICT, has no no_std support whatsoever. Therefore, we would still need our own Once implementation on no-std.

[jplatte]

Yeah, it doesn't (yet): matklad/once_cell#61

[taiki-e]

I don't think this is correct, though. The vendored code is the no_std version of lazy_static using a spinlock. We're vendoring it because it's not possible to conditionally enable a feature flag of a dependency when tracing's "std" feature is disabled, only to disable feature flags. once_cell, AFAICT, has no no_std support whatsoever. Therefore, we would still need our own Once implementation on no-std.

Oh, you are right. I missed no-std support is only unsync module.

[jplatte]

Done in #2147.