[libc++] Support int8_t and uint8_t in integer distributions as an extensionIn D125283, we ensured that integer distributions would not compile whenused with arbitrary unsupported types. This effe
[libc++] Support int8_t and uint8_t in integer distributions as an extensionIn D125283, we ensured that integer distributions would not compile whenused with arbitrary unsupported types. This effectively enforced whatthe Standard mentions here: http://eel.is/c++draft/rand#req.genl-1.5.However, this also had the effect of breaking some users that wereusing integer distributions with unsupported types like int8_t. Since wealready support using __int128_t in those distributions, it is reasonableto also support smaller types like int8_t and its unsigned variant. Thiscommit implements that, adds tests and documents the extension. Note thatwe voluntarily don't add support for instantiating these distributionswith bool and char, since those are not integer types. However, it istrivial to replace uses of these random distributions on char using int8_t.It is also interesting to note that in the process of adding testsfor smaller types, I discovered that our distributions sometimes don'tprovide as faithful a distribution when instantiated with smaller types,so I had to relax a couple of tests. In particular, we do a really badjob at implementing the negative binomial, geometric and poisson distributionsfor small types. I think this all boils down to the algorithm we use instd::poisson_distribution, however I am running out of time to investigatethat and changing the algorithm would be an ABI break (which might bereasonable).As part of this patch, I also added a mitigation for a very likelyinteger overflow bug we were hitting in our tests in negative_binomial_distribution.I also filed http://llvm.org/PR56656 to track fixing the problematicdistributions with int8_t and uint8_t.Supersedes D125283.Differential Revision: https://reviews.llvm.org/D126823
show more ...
[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-namingEnsure that parameter names have the style `__lower_case`Reviewed By: ldionne, #libcSpie
[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-namingEnsure that parameter names have the style `__lower_case`Reviewed By: ldionne, #libcSpies: aheejin, sstefan1, libcxx-commits, miyukiDifferential Revision: https://reviews.llvm.org/D129051
[libc++] Replace modulus operations in std::seed_seq::generate with conditional checks.Abseil benchmarks suggest that the conditional checks result in faster code (4-5x)as they are compiled into c
[libc++] Replace modulus operations in std::seed_seq::generate with conditional checks.Abseil benchmarks suggest that the conditional checks result in faster code (4-5x)as they are compiled into conditional move instructions (cmov on x86).Reviewed By: #libc, philnik, MordanteSpies: pengfei, Mordante, philnik, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D125329
[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suiteThis should make CI consistent on all the compilers we support. Most ofthis patch is working around
[libc++] Define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER whenever we enable warnings in the test suiteThis should make CI consistent on all the compilers we support. Most ofthis patch is working around various warnings emitted by GCC in our codebase, which are now being shown when we compile the tests.After this patch, the whole test suite should be warning free on allcompilers we support and test, except for a few warnings on GCC thatwe silence explicitly until we figure out the proper fix for them.Differential Revision: https://reviews.llvm.org/D120684
[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.All supported compilers that support C++20 now support concepts. So, remove`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBC
[libc++] Replace _LIBCPP_HAS_NO_CONCEPTS with _LIBCPP_STD_VER > 17. NFCI.All supported compilers that support C++20 now support concepts. So, remove`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly inthe tests, remove `// UNSUPPORTED: libcpp-no-concepts`.Differential Revision: https://reviews.llvm.org/D121528
[libc++] Explicitly reject URNG types with signed result_types.Fixes #48965.Differential Revision: https://reviews.llvm.org/D120630
[libc++] Revert "Protect users from relying on detail headers" & related changesThis commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,which were related to the original commit).
[libc++] Revert "Protect users from relying on detail headers" & related changesThis commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,which were related to the original commit). As landed, 5aaefa51 hadunintended consequences on some downstream bots and didn't have propercoverage upstream due to a few subtle things. Implementing this issomething we should do in libc++, however we'll first need to addressa few issues listed in https://reviews.llvm.org/D106124#3349710.Differential Revision: https://reviews.llvm.org/D120683
[libc++] Explicitly reject `uniform_int_distribution<bool>` and `<char>`.`uniform_int_distribution<T>` is UB unless `T` is one of the non-character,non-boolean integer types (`short` or larger). H
[libc++] Explicitly reject `uniform_int_distribution<bool>` and `<char>`.`uniform_int_distribution<T>` is UB unless `T` is one of the non-character,non-boolean integer types (`short` or larger). However, libc++ has neverenforced this. D114129 accidentally made `uniform_int_distribution<bool>`into an error. Make it now *intentionally* an error; and likewise for thecharacter types and all user-defined class and enum types; but permit`__[u]int128_t` to continue working.Apply the same static_assert to all the integer distributions.Differential Revision: https://reviews.llvm.org/D114920
[libcxx][modules] protects users from relying on detail headerslibc++ has started splicing standard library headers into much morefine-grained content for maintainability. It's very likely that ou
[libcxx][modules] protects users from relying on detail headerslibc++ has started splicing standard library headers into much morefine-grained content for maintainability. It's very likely that outdatedand naive tooling (some of which is outside of LLVM's scope) willsuggest users include things such as <__ranges/access.h> instead of<ranges>, and Hyrum's law suggests that users will eventually begin torely on this without the help of tooling. As such, this commitintends to protect users from themselves, by making it a hard error foranyone outside of the standard library to include libc++ detail headers.Differential Revision: https://reviews.llvm.org/D106124
[libc++] Guard warning pragmasThis makes the GCC output even cleaner!Reviewed By: ldionne, #libcSpies: mstorsjo, Quuxplusone, Mordante, libcxx-commitsDifferential Revision: https://reviews.ll
[libc++] Guard warning pragmasThis makes the GCC output even cleaner!Reviewed By: ldionne, #libcSpies: mstorsjo, Quuxplusone, Mordante, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D119295
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Now we'll notice if a header forgets to include this magic phrase.Differential Revision: https://reviews.llvm.org/D1188
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Now we'll notice if a header forgets to include this magic phrase.Differential Revision: https://reviews.llvm.org/D118800
[libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)
[libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)`so that we can do a big search-and-replace for `!defined(_LIBCPP_HAS_NO_CONCEPTS)`back into `_LIBCPP_STD_VER > 17` when we're ready to abandon support for concept-syntax-lesscompilers.Differential Revision: https://reviews.llvm.org/D118748
[libc++] Fix LWG3422 "Issues of seed_seq's constructors"https://cplusplus.github.io/LWG/issue3422Also add a static_assert to check the "Mandates:" on theiterator-pair constructor. Oddly, the `In
[libc++] Fix LWG3422 "Issues of seed_seq's constructors"https://cplusplus.github.io/LWG/issue3422Also add a static_assert to check the "Mandates:" on theiterator-pair constructor. Oddly, the `InputIterator` parameteritself is merely preconditioned, not constrained, to satisfy theinput iterator requirements.Also drive-by rename `init` to `__init`.Differential Revision: https://reviews.llvm.org/D117962
[libc++] [ABI BREAK] Conform lognormal_distribution::param_type.Fixes #52906.Differential Revision: https://reviews.llvm.org/D116344
[libc++] Start using `arc4random()` to implement `std::random_device` on AppleOn Apple platforms, arc4random is faster than /dev/urandom, and it isthe recommended user-space RNG according to Apple
[libc++] Start using `arc4random()` to implement `std::random_device` on AppleOn Apple platforms, arc4random is faster than /dev/urandom, and it isthe recommended user-space RNG according to Apple's own OS folks.This commit adds an ABI switch to guard ABI-break-protections instd::random_device, and starts using arc4random instead of /dev/urandomto implement std::random_device on Apple platforms.Note that previously, `std::random_device` would allow passing a customtoken to its constructor, and that token would be interpreted as the nameof a file to read entropy from. This was implementation-defined andundocumented. After this change, Apple platforms will be using arc4random()instead, and any custom token passed to the constructor will be ignored.This behavioral change will also impact other platforms that use thearc4random() implementation, such as OpenBSD. This should be fine sincethat is effectively a relaxation of the constructor's requirements.rdar://86638350Differential Revision: https://reviews.llvm.org/D116045
[libc++] Alphabetize header #includes. NFCI.The NFC part of D116809. We still want to enforce this in CI,but the mechanism for that is still to-be-determined.Differential Revision: https://revie
[libc++] Alphabetize header #includes. NFCI.The NFC part of D116809. We still want to enforce this in CI,but the mechanism for that is still to-be-determined.Differential Revision: https://reviews.llvm.org/D116809
[libc++] Partially revert 346ef5e5879eThis moves the macro definitions back to __config, but keeps theimproved documentation. 346ef5e5879e had broken the MinGW build.
[libc++][NFC] Improve documentation of the various random_device implementationsAlso, move the setting of the macro closer to its point of use, whichalso has the benefit of uncluttering `__config`.
[libc++][NFC] Reformatting in random_device.h and random.cpp
[libc++] `= delete` member functions with // = delete;Use `= delete` for member functions that are marked with `// = delete;`Reviewed By: ldionne, Quuxplusone, #libcSpies: jloser, libcxx-commit
[libc++] `= delete` member functions with // = delete;Use `= delete` for member functions that are marked with `// = delete;`Reviewed By: ldionne, Quuxplusone, #libcSpies: jloser, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D115291
[libc++] Extract __clamp_to_integral to its own headerIn addition to being more consistent with our approach for helpers, thissolves an actual issue where <cmath> was using numeric_limits but neve
[libc++] Extract __clamp_to_integral to its own headerIn addition to being more consistent with our approach for helpers, thissolves an actual issue where <cmath> was using numeric_limits but neverincluding the <limits> header directly. In a normal setup, this is notan issue because the <math.h> header included by <cmath> does include<limits>. However, I did stumble upon some code where that didn't work,most likely because they were placing their own <math.h> header in frontof ours. I didn't bother investigating further.Differential Revision: https://reviews.llvm.org/D115282
[libc++] Fix `uniform_int_distribution` for 128-bit result typeFixes https://llvm.org/PR51520. The problem is that `uniform_int_distribution`currently uses an unsigned integer with at most 64 bits
[libc++] Fix `uniform_int_distribution` for 128-bit result typeFixes https://llvm.org/PR51520. The problem is that `uniform_int_distribution`currently uses an unsigned integer with at most 64 bits internally, whichis then casted to the desired result type. If the result type is `int64_t`,this will produce a negative number if the most significant bit is set,but if the result type is `__int128_t`, the value remains non-negativeand will be out of bounds for the example in PR#51520. (The reason whyit also seems to work if the upper or lower bound is changed isbecause the branch at [1] will then no longer be taken, and properrejection sampling takes place.)The bigger issue here is probably that `uniform_int_distribution` can beinstantiated with `__int128_t` but will silently produce incorrect results(only the lowest 64 bits can ever be set). libstdc++ also supports `__int128_t`as a result type, so I have simply extended the maximum width of theinternal intermediate result type.[1]: https://github.com/llvm/llvm-project/blob/6d28dffb6/libcxx/include/__random/uniform_int_distribution.h#L266-L267Differential Revision: https://reviews.llvm.org/D114129
[libc++] Granularize the <random> header. NFCI.Actually there's one functional change here, which is that users canno longer depend on <random> to include all of C++20 <concepts>. Thatinclusion i
[libc++] Granularize the <random> header. NFCI.Actually there's one functional change here, which is that users canno longer depend on <random> to include all of C++20 <concepts>. Thatinclusion is so new that we believe nobody should be depending on ityet, even in the presence of Hyrum's Law. We keep the includes of <vector>,<algorithm>, etc., so as not to break pre-C++20 Hyrum's Law users.Differential Revision: https://reviews.llvm.org/D114281
[libcxx] Move all algorithms into their own headersThis is a fairly mechanical change, it just moves each algorithm intoits own header. This is intended to be a NFC.This commit re-applies 7ed7d4
[libcxx] Move all algorithms into their own headersThis is a fairly mechanical change, it just moves each algorithm intoits own header. This is intended to be a NFC.This commit re-applies 7ed7d4ccb899, which was reverted in 692d7166f771because the Modules build got broken. The modules build has now beenfixed, so we're re-committing this.Differential Revision: https://reviews.llvm.org/D103583Attribution note----------------I'm only committing this. This commit is a mix of D103583, D103330 andD104171 authored by:Co-authored-by: Christopher Di Bella <[email protected]>Co-authored-by: zoecarver <[email protected]>