lock_api doesn't build for targets without atomics

[Xiretza]

lock_api unconditionally compiles remutex.rs, which imports core::sync::atomic::AtomicUsize. This struct is not available on targets without atomics, so it would be nice to be able to just use this library without the remutexes (i.e. by hiding them behind a feature flag, since rust-lang/rust#64797 doesn't exist yet).

$ cargo build --target riscv32imc-unknown-none-elf
   Compiling lock_api v0.4.2 (/tmp/parking_lot/lock_api)
error[E0432]: unresolved import `core::sync::atomic::AtomicUsize`
  --> lock_api/src/remutex.rs:19:20
   |
19 |     sync::atomic::{AtomicUsize, Ordering},
   |                    ^^^^^^^^^^^ no `AtomicUsize` in `sync::atomic`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `lock_api`

To learn more, run the command again with --verbose.

[Amanieu]

This seems like a bug in the RISC-V target. lock_api only depends on atomic load/store of usize, which should be available on all targets. The target descriptions in compiler/rustc_target/src/spec/ should have max_atomic_width: Some(32) instead of Some(0) to indicate this (or just leave it empty since it defaults to the pointer size).

[Xiretza]

The riscv32imc target really doesn't have any atomics instructions, that would be the a extension - this makes it unsuitable for multi-processor environments, of course, but simple microcontrollers can do without atomics.

[Amanieu]

The a extension adds atomic read/modify/write instructions lr/sc/amo*. However the base ISA still has standard load/store instructions which are atomic when used on aligned addresses. lock_api only uses AtomicUsize::load and AtomicUsize::store which map to normal load/store instructions.

The other operations on AtomicUsize will continue being unavailable because of atomic_cas: false in the target spec. Changing max_atomic_width will only expose load and store operations on atomic types.

[Xiretza]

Ah, I see! I'll try to take this upstream then, thanks.