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

[Aaron Ballman via libcxx-commits]

AaronBallman wrote:

> > > @AaronBallman It seems like you're concerned about removing the `_Atomic(T)` extension, and I understand that. What would you think of merely adding a warning that says "you should include <stdatomic.h> to get consistent behavior"? The rest of the plan can stay the same: libc++ always provides `<stdatomic.h>` in all standard modes and uses `_AtomicExt` under the hood.
> > 
> > 
> > So we'd end up with `_Atomic` and `_AtomicExt` and they're different (incompatible) types with different semantics? Won't this still cause ABI compatibility issues for libc++ because under the hood std::atomic will be `_Atomic` in older libc++ and `_AtomicExt` in newer libc++?
> > Do you envision us adding additional builtins for the new `_AtomicExt` type as well?
> 
> Personally I envisioned it simply as adding `ALIAS("_AtomicExt", _Atomic, KEYALL)` to `TokenKinds.def`, except that its usage isn't diagnosed in C++.

Oh! That's different than what I was picturing, thank you for clarifying. That seems far less frightening. I think the idea could get traction within Clang; it's probably worth exploring the idea to make sure there aren't surprises (e.g., are there issues with name mangling if we make them an alias, etc) and assuming all goes well, posting an RFC to get community buy-in.

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