From the comment above the job being changed here, it seems that this
job was supposed to be run with MSRV Rust but it uses the latest stable
instead. Let's make it work as it was intended.
This would hopefully catch us unintentionally bumping the MSRV.
- `cfg(target_has_atomic)` is stable now, use that.
- Hardcode in `build.rs` the list of targets with load/store but no CAS,
since `cfg(target_has_atomic_load_store)` is not stable yet.
- Do not try to autodetect whether `portable-atomic` is needed or not,
just let the user control it directly. If the user doesn't explicitly
enable `portable-atomic` and native atomics are unavailable, the
features requiring it will be missing.
from [this](https://doc.rust-lang.org/beta/unstable-book/compiler-flags/sanitizer.html#threadsanitizer)
> To work correctly ThreadSanitizer needs to be "aware" of all synchronization operations in a program. It generally achieves that through \[...\] and compile time instrumentation (e.g. atomic operations). Using it without instrumenting all the program code can lead to false positive reports.
and the example uses -Zbuild-std ... of course, std has to be instrumented. Adding -Zbuild-std fixes it, indeed.
the implementation uses a 64-bit atomic on `x86` to avoid the `ANCHOR` variable and the address
space limitation seen with the x86_64 compilation target
this PR also adds the i686-linux-musl target to the test matrix to exercise the new implementation
closes#231
