core: vendor lazy_static and spin for no_std support

[thombles]

Following the suggested fix on #365: #365 (comment)

tracing-core's use of spin is feature-gated. lazy_static is vendored for either feature but I've modified it to respect our feature flags. I've also removed doc comments that no longer compile and suppressed a couple of warnings with the lints that are now being applied.

At this point

• Including this in another project with std lazy_static works
• Tracing unit tests pass both with and without --no-default-features

However I feel like a bull in a china closet, copying in gobs of dependencies to an unfamiliar project. Feedback about how best to arrange this will be greatly appreciated!

Fixes #365

[hawkw]

Thanks so much for working on this, I really appreciate it!

I noticed a few things that will need to be addressed before we can merge this — in particular, I think the doctests in the vendored code is breaking the build, and we need to be able to reexport a Once type in tracing for the macros to work correctly. Additionally, I think it's important that the vendored code not be publicly accessible to user code, or at least doc(hidden) when it has to be reexported.

[hawkw]

Also, would you mind adding "Fixes #365" to the PR description before we merge this? Thanks!

[thombles]

Apologies, my first attempt was far more broken than I realised! I tripped over rust-lang/cargo#5015 - I thought I was building without std but I wasn't. Thanks for the detailed feedback!

In the end I removed all the spin tests as they depend on std. The lints helped me prune out the things we weren't using. My first thought was to leave the vendored code as close to upstream as possible but I've been nudged towards just including what we need.

My only lingering concern is that tracing points at tracing-core 0.1.7, which lacks our new Once export. I confirmed it builds if I set the path manually. I guess it will be okay if they're released in sync. Do I need to do anything about it for this PR?

[hawkw]

My only lingering concern is that tracing points at tracing-core 0.1.7, which lacks our new Once export. I confirmed it builds if I set the path manually. I guess it will be okay if they're released in sync. Do I need to do anything about it for this PR?

Yes, it would be great if you would do the following:

• bump tracing-core's version to 0.1.8
• set thetracing-core dependency version in tracing's Cargo.toml to version 0.1.8
• add path = "../tracing-core"that dependency

Then everything should build successfully on CI, and we can publish a new version of tracing-core after this merges.

[hawkw]

Hmm, actually...tracing-core doesn't actually use spin::Once, right? Just `spin::Mutex?

If that's the case, can we just move the vendored spin::Once into tracing, and leave spin::Mutex in tracing-core? That way, we don't need to bump the version dependency on tracing-core. I think this would be a better approach, since there isn't really any reason the vendored Once needs to be in tracing-core...

[thombles]

Hmm, actually...tracing-core doesn't actually use spin::Once, right? Just `spin::Mutex?

tracing-core doesn't directly, but the spin variant of the vendored lazy_static does unfortunately.

I guess another possibility is to let tracing continue to depend on crates.io spin, independently of the vendored Once in tracing-core. Everyone's been compiling it until now anyway. Would that be better, or should I go for the version bump?

[hawkw]

Hmm. tracing still needs some kind of no-std compatible Once. I guess let's move forward with the version bump...it seems less bad than vendoring two separate versions of Once...

[hawkw]

okay, this looks good to me. thanks so much for working on this!