Add feature to support platforms without atomic CAS

[taiki-e]

Some no-std targets (e.g., ARMv6-M) do not support atomic CAS operations and cannot use Arc, Atomic*::compare_exchange, etc. And on those targets, bytes currently fails to build (#461).

EDIT: This PR has been updated to adopt the third idea of #573 (comment).

Alternatively, let the processing of those targets to an external crate such as portable-atomic, avoiding the implementation of our own logic

Perhaps it would be preferable to start with the third and then select the first or second in the future if necessary?

The latest version of this PR uses portable-atomic to support platforms without atomic CAS.
This currently uses the feature name ("extra-platforms") mentioned by carllerche in #461 (comment).

old version

This patch detects those targets using the TARGET environment variables provided by cargo for the build script, and a list of targets that do not support atomic CAS operations.

This way is the same as the way we recently adopted in futures and valuable, and was originally inspired by the way heapless and defmt do, but this doesn't maintain the target list manually. (It's not really fully automated, but it's very easy to update.)

Refs:

• enable Atomic*.{load,store} for ARMv6-M / MSP430 rust-lang/rust#51953
• Remove uses of unstable feature(cfg_target_has_atomic) rust-lang/futures-rs#2400
• Fix build error with targets that do not support atomic CAS operations valuable#12

Closes #461
Closes #573

[MathiasKoch]

Any reason this is still just a draft?

[ia0]

@Darksonn you seem to be the most active reviewer on this crate based on the latest commits.

Could you provide some light regarding the status of this PR? What is blocking it from being merged? What comes to mind would be:

• Unclear whether there is a user need, but the PR has 7 thumbs up so far.
• Unclear whether it is technically correct/sustainable, but there hasn't be any request for change.
• Unclear who should review it and has time to do so. If this is true, what would you suggest? Could the community help?

[Darksonn]

Taking new dependencies is always complicated. It raises various questions about to what extent we lock ourselves in for the future, what effect it has on MSRV and so on. I also see that there's another PR that uses a different crate for atomics, and I'll need to understand what happened there. I see that there's a bunch of discussion on the other PR.

Other than that, sometimes what a PR needs is just to ping someone and spur them to action. I'm at a conference right now, but I can try to take a look when I fly back to Europe (if I find the energy to look at my laptop during the flight).

[ia0]

Taking new dependencies is always complicated. It raises various questions about to what extent we lock ourselves in for the future, what effect it has on MSRV and so on.

Makes sense, let me try to give you some pointers in that regard, so you don't spend too much time doing archaeology.

I also see that there's another PR that uses a different crate for atomics, and I'll need to understand what happened there. I see that there's a bunch of discussion on the other PR.

Even though #573 is more recent and has more discussions, those discussions are reflected in this PR. The main point of contention as I see it (anyone correct me if I'm wrong) is how portable-atomic was designed back then, essentially preferring backend selection with --cfg rather than --feature (to avoid accidental unsoundess to the price of user convenience). But this point of contention has been resolved since then:

• Crates like heapless and usb-device started using portable-atomic instead of atomic-polyfill.
• portable-atomic ended up providing a feature as collaborative work between the persons involved in the Support atomic-polyfill for targets without native atomics #573 discussion.

So my understanding would be that portable-atomic is now the defacto crate for portable atomic operations (that's even advertised on https://docs.rs/atomic-polyfill).

I'm at a conference right now, but I can try to take a look when I fly back to Europe (if I find the energy to look at my laptop during the flight).

No worries, I was just checking. Good luck at the conference!

[ia0]

Should a new PR be opened? Possibly with a smaller diff such that it's easier to review?

[Darksonn]

Sorry, I never got around to it.

I'm happy to accept this feature, with the following changes:

• We should document that this feature exists in the readme or lib.rs.
• We should clarify that the list of platforms supported by extra-platforms is subject to change, and that we may drop platforms without a breaking change.

Also, the merge conflicts will need to be fixed.

@taiki-e

[marius-meissner]

@Darksonn I'm pleased that things still seem to be moving forward here. :)

@taiki-e: What is your current capacity? We (me or @HusseinAbdelhamid) could offer to support here and solve the last two changes, including merge conflicts.
In any case, we have already been temporarily maintaining a patch (https://github.com/atlas-aero/rt-bytes) for some time. It would therefore help us a lot if this PR is finally completed.
Anyway, thanks for your great work so far!

[tjoslin]

@Darksonn as an exercise to aid in getting this merged, I squashed these commits and rebased the result onto master with an updated portable-atomic version while resolving the merge conflicts in #751