Use autocfg instead of unstable feature(cfg_target_has_atomic)

[taiki-e]

Instead of depending on unstable features of the compiler, use autocfg crate to detect if atomic CAS is available.

This completely removes the dependency on unstable features from crates other than futures and futures-util.
I'm planning to remove the dependency on unstable features from all crates, which is the first step in that plan.

feature(cfg_target_has_atomic) is propagated to the core/alloc imported in all dependencies if any of the dependencies graph crates are uses feature(cfg_target_has_atomic), so it works if the user just enables the feature(cfg_target_has_atomic). EDIT: See #2294 (comment)
(Previously you had to enable both feature(cfg_target_has_atomic) and futures crate's cfg-target-has-atomic feature.)

Unfortunately, this has some (potential) concerns about breakage:

• As said in futures-core 1.0 release #2207 (comment), there are concerns about compatibility with non-cargo build systems that do not run build-scripts.
  If the build script is not called on these build systems, modules/types that require cfg(target_has_atomic = "ptr"), such as channels, will not compile. However, I think this can workaround by always treating cfg(target_has_atomic = "ptr") as true when the build script doesn't run. (This should behave exactly the same as current futures without cfg-target-has-atomic feature.)
  Also, I haven't actually tested it, but Bazel (cargo-raze) and Buck(reindeer) seem to support build scripts, so I'm not too worried about this.
• Compile time will probably increase a little. autocfg is lightweight and widely used, and this is a much smaller increase compared to time reduced by futures-util: Migrate from pin-project to pin-project-lite #2273, so I don't think this is really a problem.
• The biggest concern about this is that modules/types that require cfg(target_has_atomic = "ptr") will not compile if autocfg does not work as expected. See 1.48 beta broken on mips due to copy_file_range EOVERFLOW rust#78979, IndexMap compilation fails "expected 3 type arguments" indexmap-rs/indexmap#151, 1.5.0 breaks h2 build indexmap-rs/indexmap#144, 1.29 fails to build on a Windows networked drive rust#54216, Can no longer build on custom target rust-num/num-traits#177, i128 no_std rust-num/num-complex#83 for the actual case where similar issue occurred.
  A known workaround for this seems to be to add a cargo feature that always treats cfg(target_has_atomic = "ptr") as true, like Add a feature to explicitly enable "std" indexmap-rs/indexmap#145, Trust the "i128" feature rust-num/num-traits#185.

I haven't implemented workarounds yet, but I think there are workarounds for possible issues (basically).

Also, the approach I adopt in this PR is basically the same as the one I'm planning to use in the changes proposed in #2207.

[Nemo157]

LGTM

feature(cfg_target_has_atomic) is propagated to the core/alloc imported in all dependencies if any of the dependencies graph crates are uses feature(cfg_target_has_atomic), so it works if the user just enables the feature(cfg_target_has_atomic).

The user doesn't even need to enable this, for anyone not supporting targets like thumbv6m they can just assume that the target supports atomics, or they could use a similar autocfg script checking the existence of the futures APIs they need.

[taiki-e]

It's unfortunate that we need to use double negation, but AFAIK, this is the easiest way to implement a workaround for the first problem.

[taiki-e]

• A known workaround for this seems to be to add a cargo feature that always treats cfg(target_has_atomic = "ptr") as true, like bluss/indexmap#145, rust-num/num-traits#185.

Another workaround for this is to pass a no-op expression (empty block or unit) to autocfg and treat cfg(target_has_atomic = "ptr") as true if it fails. This allows detecting cases that fail for unrelated reasons such as io.

[cramertj]

Just seeing this now. I'm very familiar with the hassle that custom build.rs scripts like this can cause other build systems, and it'd be really nice if we didn't introduce another point of friction for those users. That said, those users are already accustomed to some friction, so it seems right to look more closely at the costs to those users vs. the benefits to futures.

It's easy for custom build systems to enable a feature flag, but running arbitrary other rust code (autocfg) at build time may or may not be simple. Is it possible to use autocfg to detect whether the feature should be used, and then go through normal feature flags to enable the behavior?

This completely removes the dependency on unstable features from crates other than futures and futures-util.
I'm planning to remove the dependency on unstable features from all crates, which is the first step in that plan.

I'm not totally sure I understand the benefits of this change. These unstable feature usages are already gated on an unstable cargo feature flag right? That is, it isn't quite clear to me what the benefit is of removing unstable feature usages that aren't enabled without explicit opt-in.

[taiki-e]

Is it possible to use autocfg to detect whether the feature should be used, and then go through normal feature flags to enable the behavior?

Do you mean adding something like indexmap-rs/indexmap#145 and rust-num/num-traits#185? If so, it's definitely possible.

These unstable feature usages are already gated on an unstable cargo feature flag right? That is, it isn't quite clear to me what the benefit is of removing unstable feature usages that aren't enabled without explicit opt-in.

I think it's nice to remove dependencies on unstable features, whether explicitly gated or not.

That said, I agree that there isn't much benefit from this patch, as the user still need to enable unstable features on the user side to actually use cfg_target_has_atomic. So I'll close this for now. EDIT: This is not correct. see #2399 (comment)