Doesn't compile for `riscv32imc-unknown-none-elf`anymore

[bjoernQ]

e.g. cargo build --no-default-features --features "alloc,use_serde,use_strum,use_numenum" --target riscv32imc-unknown-none-elf "-Zbuild-std=core,alloc,panic_abort" "-Zbuild-std-features=panic_immediate_abort" used to compile fine but doesn't anymore.

Going back the history there is some point when it works (e.g. 6e653ff4285472ee73c3dab67d2b8240e5814c53 ... but that was just randomly picked).

The line that introduced the problem:

error[E0432]: unresolved import `alloc::sync`
   --> src\mqtt\client.rs:255:16
    |
255 |     use alloc::sync::Arc;
    |                ^^^^ could not find `sync` in `alloc`

Problem is: alloc::sync is only available on targets that support atomic pointers. No idea why it works with IDF, t.b.h. - maybe because of atomic emulation there.

Since these traits are meant to be generally useful not only for ESP (and definitely not only ESP-IDF) based targets, I'd consider this to be a bug.

This currently blocks upgrading the dependency in esp-wifi

[ivmarkov]

It is because of the utils module which was created recently and which is not strictly required.

The thing is, not just this module, but a lot of other utils' stuff equates the availability of alloc with the availability of atomics support from core. The easiest solution would be to just hide this stuff behind another feature (atomics?).

I have to think it through though. Claiming to have alloc but then not having Arc is very inconvenient IMO.

[ivmarkov]

Oh, and you can always support atomics via some sort of emulation (as in disable interrupts; do your "atomic" thing; enable interrupts). This is how it is done for the riscv using the ESP-IDF. It is just that these tricks require a modification of the target metadata itself, and I don't think we can/should touch the riscv32imc-unknown-none-elf.

Perhaps, we need not just atomics-polyfill but also arc-polyfill of sorts.

[bjoernQ]

Yes, there some options. Especially since this crate is not just about our own chips in theory (while not used elsewhere, yet) it would be good to not require atomics.

The easiest solution would be to just hide this stuff behind another feature (atomics?).

That would definitely already help here

[ivmarkov]

@bjoernQ - if you can try with the latest master branch. All usages of alloc::sync are not protected with #[cfg(target_has_atomic = "ptr")] and in general all references to atomics are protected in a similar way.

Long term we might want to either:

• Depend on atomic-polyfill as the bare-metal targets do not have atomics declared so these need to be polyfilled. This - unfortunately - means that we also need an Arc polyfill as well, i.e. a new crate arc-polyfill.
• OR - we can embrace the approach of @MabezDev where we can "alter" the original bare-metal targets with Rust -C buildflags to "enrich" them so that they declare support for atomics, which are then handled using the invalid instruction trap handlers.

Any preferences as to which way we should go?

[ivmarkov]

Btw, kind of related: #15

[bjoernQ]

Awesome - this fixes the issue!

I really like #15