Vendored spin crate is not maintained upstream

[ghost]

Bug Report

cargo deny check for my project reports:

warning: 1 informational advisory found

Crate:    spin
Title:    spin is no longer actively maintained
Date:     2019-11-21
URL:      https://rustsec.org/advisories/RUSTSEC-2019-0031
Dependency tree:
spin 0.5.2
├── tracing-core 0.1.7
│   ├── tracing-subscriber 0.1.6
│   ├── tracing-log 0.1.1
│   │   └── tracing-subscriber 0.1.6
│   └── tracing 0.1.10
├── tracing 0.1.10
├── ring 0.16.9
└── lazy_static 1.4.0
    ├── wasm-bindgen-backend 0.2.55
    │   ├── wasm-bindgen-webidl 0.2.55
    │   │   └── web-sys 0.3.32
    │   │       ├── wasm-bindgen-futures 0.3.27
    │   │       │   └── wasm-bindgen-test 0.2.50
    │   │       └── ring 0.16.9
    │   └── wasm-bindgen-macro-support 0.2.55
    │       └── wasm-bindgen-macro 0.2.55
    │           └── wasm-bindgen 0.2.55
    │               ├── web-sys 0.3.32
    │               ├── wasm-bindgen-test 0.2.50
    │               ├── wasm-bindgen-futures 0.3.27
    │               ├── serde-wasm-bindgen 0.1.3
    │               ├── js-sys 0.3.32
    │               │   ├── web-sys 0.3.32
    │               │   ├── wasm-bindgen-test 0.2.50
    │               │   ├── wasm-bindgen-futures 0.3.27
    │               │   ├── serde-wasm-bindgen 0.1.3
    │               └── console_error_panic_hook 0.1.6
    │                   ├── wasm-bindgen-test 0.2.50
    ├── tracing-subscriber 0.1.6
    ├── tracing-log 0.1.1
    ├── tracing-core 0.1.7
    ├── thread_local 0.3.6
    │   └── regex 1.3.1
    │       ├── tracing-subscriber 0.1.6
    ├── ring 0.16.9

I see now you are vendoring spin. I don't think you are intending to become the new primary maintainers of spin. What are your plans regarding spin? I am in a similar situation where people are getting warnings when they use my crates (e.g. ring) and I'm interested in finding a solution that works for lots of people.

[hawkw]

Thanks for bringing this up! For now, I'm willing to maintain the code we have vendored from spin as a component of tracing-core.

However, in the future, if there is a widely used spinlock implementation we can replace the vendored code with, I'd be very happy to remove it — I don't like the potential binary bloat that can result from vendoring in this manner.

We need the vendored spin for both the mutex implementation and for Once, which is needed by our vendored v ersion of lazy_static. Our only requirement for a replacement implementation is that the lazy static crate should have a std feature flag for standard library support which can be disabled by no-std users. The vendoring is primarily due to the fact that conditional no-std support in the published lazy_static crate works in the opposite way, with a feature flag that is enabled to support no-std, and there's not really a good way in cargo to conditionally enable a feature when another feature is disabled. See #365 for details.

[hawkw]

I'd be quite happy to release and maintain a new spinlock implementation, but that isn't really a complete solution to the problem. The goal is specifically that we would depend on the same spinlock crate as any other dependencies, to avoid compiling similar but not identical code into a binary.

[ghost]

I'd be quite happy to release and maintain a new spinlock implementation, but that isn't really a complete solution to the problem. The goal is specifically that we would depend on the same spinlock crate as any other dependencies, to avoid compiling similar but not identical code into a binary.

See briansmith/ring#921 (comment). I believe the problem you have is exactly the same problem as mine, and I think the ultimate solution is likely to be the same: Find (or build) a third-party spinlock-based Lazy implementation that works for our use cases and encourage others to use it when a spinlock is warranted, and use whatever gets standardized into libstd in the RFC when libstd is available and a spinlock isn't clearly better.