[libcxx-commits] [libcxx] [libc++][Android] Always redirect <stdatomic.h> to <atomic> (PR #143036)

[Louis Dionne via libcxx-commits]

ldionne wrote:

I spoke with Nikolas about this issue just now and here's another possibility we came up with (which is a variation on option 1 above):

1. Introduce a new Clang "keyword" for `_Atomic` (same functionality, new spelling). Let's call it `_AtomicExt` for now.
2. Deprecate the existing `_Atomic` extension in Clang. After N releases, require that users include `<stdatomic.h>` before using `_Atomic` (in all C++ modes/versions). Failure to do so is an error. Using `_AtomicExt` without including `<stdatomic.h>` is fine, though.
3. Libc++ always provides `<stdatomic.h>`, which defines `_Atomic(T)` to be `std::atomic<T>`. Under the hood, libc++ keeps implementing `std::atomic` using the Clang extension (now named `_AtomicExt`).

Pros:
- Solves the ODR/ABI issues that exist with the status quo across standard modes, **but also with whether you include `<stdatomic.h>` or not**
- Does not require changing the C++ Standard
- Android gets the behavior they currently have, upstream
- There's still a way to access the original Clang extension by using the `_AtomicExt` name (potentially needed by users and needed by libc++ itself).

Cons:
- Changes the meaning of `_Atomic` on non-Android platforms, which is a breaking change. But that's handled via the migration path and it's not a silent change.
- `_Atomic(T)` means slightly different things between C and C++, but that's the route that C++23 already decided to go down. We can also probably make small changes to make both more ABI-compatible (for example https://godbolt.org/z/o53Pbffe5).

I think this is the path we both like the most so far. @AaronBallman do you have an opinion about the above? This means a bit of work, but we would end up with a much nicer story for bridging C and C++ atomics, and more consistency within our C++ support.

https://github.com/llvm/llvm-project/pull/143036