Change NO_STD_TARGET to aarch64-unknown-none 🦖

[ascjones]

Since Rust 1.68, check-no-std fails. Lots of errors missing definitions from atomic.rs e.g.

cannot find macro `atomic_int` in this scope

I have confirmed this by running the check with cargo +1.67.1 and it works okay.

This looks to be an occurrence of rust-lang/rust#106795, which is fixed by rust-lang/rust#106856, but not stabilized yet (I'm not sure exactly how to tell). In any case it works with cargo +nightly so I assume this target will be fixed in a upcoming stable release.

In the meantime I have chosen a different target which has the same property of only supporting no_std: aarch64-unknown-none. This is a tier-2 target which is guaranteed to build, see https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-2

[HCastano]

@athei since the change that broke the bpf target seems to be related to atomics, is your comment from the original PR outdated now?

Just wondering if we need to switch back to a more constrained target in the future, or if keeping the aarch64 one is fine

[ascjones]

We can certainly switch back to bpf once the fix is stabilized, it seems that works again on nightly. Although since atomics are in core and we are doing -Zbuild-std="core,alloc", I'm not sure whether the fix is that atomics are enabled again for bpf. So we need some clarity.

I'm wondering whether we could/should create our own custom target as per https://docs.rust-embedded.org/embedonomicon/custom-target.html.

[ascjones]

This is the relevant issue for atomics rust-lang/rust#106795

[athei]

I'm not sure whether the fix is that atomics are enabled again for bpf. So we need some clarity.

bpf does not have atomics. So that can't be the fix. The core library does handle this case with conditional compilation. There might just be a bug with this esoteric target.

Just wondering if we need to switch back to a more constrained target in the future, or if keeping the aarch64 one is fine.

I think we can stick with aarch64.