Implement cfg portable_atomic_critical_section

[BjornTheProgrammer]

It is really hard to keep track if critical-section should be enabled with a complex project of many different dependencies with feature flags, which all require critical-section to be added.

As such, the critical-section feature should get an alias called portable_atomic_critical_section cfg, just like how unsafe-assume-single-core feature has the alias portable_atomic_unsafe_assume_single_core cfg, to maintain feature parity.

[taiki-e]

Unfortunately, unlike Cargo features, it is not possible to enable optional dependencies using cfg.

Currently, to use a critical-section implementation, we must depend on critical-section crate; the logic for sharing a critical-section implementation in the dependency graph is not considered a stable API and is incompatible depending on which Cargo features of critical-section crate are enabled.

[BjornTheProgrammer]

@taiki-e I think I've found a solution to that issue, by using

[target.'cfg(portable_atomic_critical_section)'.dependencies]

It's possible to have the dependency load upon setting a cfg flag. The seem to mostly be passing also (except for some fetch request fails, and some strange error about "${cmd}" "$@")

[BjornTheProgrammer]

I've verified that this actually works (at least on newer versions of rust), is there any plan to implement this? Otherwise I'll close this pull request.

[taiki-e]

The problem with the current approach is that the way cargo and crates.io handle cfg-ed dependencies is not very good, confuses users, and some people complain when new dependency appears in Cargo.lock (even if it never actually builds).
(e.g., crossbeam-rs/crossbeam#487 (comment), crossbeam-rs/crossbeam#665, tokio-rs/bytes#411, tokio-rs/bytes#400, etc.)

And the known workaround for that problem is to make the dependency optional (crossbeam-rs/crossbeam#666), which conflicts with your request here.

[taiki-e]

Please revert any version change. It is auto-handled at the time of release.

Also, since this is a new interface addition, the minor version should be increased, not the patch version (1.8.0 instead of 1.7.1).

[taiki-e]

I feel it is a bit misleading to use the same term to describe unsafe-assume-single-core, which cfg existed before 1.0 and then the Cargo feature was added, and critical-section, which is the opposite situation.

[taiki-e]

If my memory of the current Cargo limitations is correct, I think that it is better to have the critical-section crate side expose an API that can be used appropriately regardless of which Cargo features of critical-section crate are enabled.

I don't think it would be technically difficult to support it on critical-section, but unfortunately critical-section v1 supports 64-bit state even on 32-bit targets, so I don't think the critical-section maintainer would want to do that on critical-section v1 for performance reasons.