[libcxx-commits] [libcxx] [libcxx] applies integer-like changes from [P2393R1] (PR #74161)

[Christopher Di Bella via libcxx-commits]

cjdb wrote:

>  IIUC, we have the following integer-class types in Clang: `__int128_t`, `__uint128_t` and `_BitInt(N)` -- are there more? Do we "support" them, and if so, in what places? It seems like `std::atomic` intentionally doesn't support `_BitInt`, see https://github.com/llvm/llvm-project/blob/main/libcxx/test/libcxx/atomics/bit-int.verify.cpp#L11, but I don't know about other classes.
> 
> If the answer is "yes, those are integer-class types, we support them and they should work in Ranges", then I think we should add some tests with those types to lock down the intent of P2393R1. We might not end up testing exactly the diff in this patch because of conversion behavior which might not strictly require those casts, but I think it would be important to make sure that they work before claiming support for P2393R1. WDYT?

Yes to `__int128` and `unsigned __int128`. "libc++ only supports integral types that the compiler supports" was a design decision early in the libc++ ranges design (see [here](https://github.com/llvm/llvm-project/blob/main/libcxx/include/__iterator/concepts.h#L82-L86)). I would prefer to support `_BitInt(N)`, but I'm not against supporting it on a best-effort basis (i.e. fix bugs as they are filed). My guess is that `std::atomic` has potential hardware-level atomic constraints, whereas ranges don't have that extra restriction.

A cursory glance tells me that there aren't any tests, so I'll fix those up tomorrow.

> Was the paper voted in as a DR?

Yes, it resolves [LWG 3366](https://cplusplus.github.io/LWG/issue3366) and [LWG 3376](https://cplusplus.github.io/LWG/issue3376).

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