This will let us deprecate the declarations without triggering warnings in Abseil itself.
PiperOrigin-RevId: 906360966
Change-Id: Iee362ac0eac647909ef38003280f1179813f764d
Most usages of absl::void_t compile fine with std::void_t, so we migrate them here. A few don't compile due to overly eager template instantiations, so we leave those.
PiperOrigin-RevId: 897231619
Change-Id: Iad34101916dac2b995257ebd5d6aacb9a0acfa32
This will let us deprecate the declarations without triggering warnings in Abseil itself.
PiperOrigin-RevId: 894202105
Change-Id: I57bb2a1647be1fedf9b724a07042fd0f564ce074
Consolidate the mocking requirements so that mock detection is mediated
via the MockingAccess class
* HasInvokeMock has been deduplicated; MockingAccess now owns it
* InvokeMock is done via MockingAccess::InvokeMock
* In absl::BitGenRef, if a class has a conversion operator that is used.
* `friend class MockingAccess` is now the only mocking friend, except for backwards compat.
- friend DistributionCaller is now unnecessary.
- friend BitGenRef is now unnecessary.
- friend MockHelpers now unnecessary.
PiperOrigin-RevId: 889366369
Change-Id: I288cd60f6ac13b257c10ec3268d96828f1e61db6
absl::variant, and related types
The corresponding headers are removed from cc files, but kept in
headers to prevent breakages from transitive dependencies.
PiperOrigin-RevId: 872421685
Change-Id: I867d4c3f7c9e422289c63816d44719b0530fb0a6
for the Randen entropy pool.
https://github.com/abseil/abseil-cpp/pull/1872 reports that since
we leak the pointer but no variable holds its address, Valgrind
reports a leak. The PR contains a proposed fix, but I believe this
is simpler.
PiperOrigin-RevId: 749868815
Change-Id: I222fc3202b7a38b8ff960c2398dbf2636e60e490
absl::FastTypeId<Type>() evaluates at compile-time to a unique id for the
passed-in type. These are meant to be good match for keys into maps or
straight up comparisons.
Previously this was an internal implemention detail used by a few libraries.
This is now a supported utility function.
PiperOrigin-RevId: 743194478
Change-Id: Ie01ed8a2850696ee661acb91726252adb4c20538
In this change, //absl/status is intentionally excluded because of
complication with SWIG compatibility. This may be handled separately.
PiperOrigin-RevId: 731387819
Change-Id: I71bf2e02f3a477d65575d467f5e5ab163846d31e
If the user overrides -march e.g. via BAZEL_CXXOPTS it may conflict with
the -march override for Randen. So instead use a target attribute which
works on clang and gcc.
PiperOrigin-RevId: 728408888
Change-Id: Ie870600a80fb25f95b53f5e87bb9cc7ade53d69d
If the user overrides -march e.g. via BAZEL_CXXOPTS it may conflict with
the -march override for Randen. So instead use a target attribute which
works on clang and gcc.
PiperOrigin-RevId: 728313249
Change-Id: Ifdbf5430fbec9febdab844b8c325f9d1c7518c82
ABSL_HAVE_ACCELERATED_AES is unrelated to whether AES is supported at
runtime, so replace the ABSL_HAVE_ACCELERATED_AES check with a call to
CPUSupportsRandenHwAes() to do runtime detection.
Moreover, nothing else refers to ABSL_INTERNAL_DISABLE_AES besides this
benchmark program, so stop checking for it.
PiperOrigin-RevId: 725351190
Change-Id: Ieddb0724095db060cc5defc7c09e030b3bbafd6f
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1819
Fix the following error:
absl/random/internal/randen_detect.cc:123:12: error: no member named 'nullopt' in namespace 'std'; did you mean 'absl::nullopt'?
123 | return std::nullopt;
| ^~~~~~~~~~~~
| absl::nullopt
absl/types/optional.h:86:43: note: 'absl::nullopt' declared here
86 | ABSL_INTERNAL_INLINE_CONSTEXPR(nullopt_t, nullopt,
| ^
Merge b9a2d3920a into 7253ff8f95
Merging this change closes#1819
COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1819 from clementperon:master b9a2d3920a
PiperOrigin-RevId: 722599523
Change-Id: Ie66cbf9daf3b115668194da8b74acd6a43e12a03
The __builtin_cpu_supports path seems to cause problems on certain builds, let's remove it.
PiperOrigin-RevId: 717993600
Change-Id: I69568c17dc768a5edd097709884ba07f2c78db91
This lets us dynamically determine if we should attempt to use HW
instructions for AES.
PiperOrigin-RevId: 716350656
Change-Id: I1ead17b7b44373850b3591307b7f6d3f9147d5f9
instead of our custom ones from before the Bazel rules existed.
Also add the missing rules_cc to WORKSPACE, since we already had
it in MODULE.bazel
PiperOrigin-RevId: 715006932
Change-Id: Ibb38a78c115a7dc2983426455bb271162795846f
Linux "latest" containers updated to
GCC 14.2
CMake 3.31.2
Bazel 8.0.0
Included are various fixes to get these versions to work.
Bazel now references repositories by their canonical names from the
Bazel Central Registry. For example, Abseil is now @abseil-cpp instead
of @com_google_absl, and GoogleTest is now @googletest instead of
@com_google_googletest. Users still using the old WORKSPACE system may
need to use `repo_mapping` on repositories using the old names. See
`WORKSPACE.bazel` in this commit for an example.
PiperOrigin-RevId: 709102146
Change-Id: I02327ed4f8fb947766480bdeef2b1930a7f831eb
There is no documentation that says zero isn't okay, and the closed interval
[0, k] described by the documentation is perfectly well-defined even when k is
zero. As far as I can tell, there is no reason *not* to support zero: a random
variable that always returns the same value is still a random variable.
absl::Uniform will happily generate on the interval [0, 1) for the same
reason.
PiperOrigin-RevId: 694649518
Change-Id: Ib940406f762a30e27c19c846c45bd908ae8411c3
In order to avoid unrelated diffs in future changes that touch this code.
PiperOrigin-RevId: 694625990
Change-Id: I51ac54438a977f38c54c7638701d9ff3a259a58b
See some relevant context on this project in 254b3a5326. This type existed to support the incremental migration of added validation to MockingBitGen, validating that the returned value from absl::Uniform() is in bounds. All known cases where an out-of-bounds value was returned have been fixed and migrated to use MockingBitGen.
PiperOrigin-RevId: 693836317
Change-Id: I04f54b7b4856f4280580b294194ce2c25a18e9b1
This makes MockUniform fail if the action is specified to return an out of bounds value.
Examples that will fail:
absl::Uniform(gen, 1, 4) -> 42
absl::Uniform(gen, 1, 4) -> 4: [1, 4)
absl::Uniform(absl::IntervalOpenClosed, gen, 1, 4) -> 1: (1, 4]
Examples that will pass:
absl::Uniform(gen, 1, 4) -> 3
absl::Uniform(gen, 1, 4) -> 1: [1, 4)
absl::Uniform(absl::IntervalClosed, gen, 1, 4) -> 4: [1, 4]
Special case: the empty range always returns its boundary, so this case passes:
absl::Uniform(absl::IntervalOpen, 1, 1) -> 1: (1, 1)
If this breaks your test, your test has a bug: it's relying on an absl::Uniform() call that returns an impossible value. The UnvalidatedMockingBitGen type temporarily exists to allow for disabling the validation to give a bit of time to fix the test, but this type will go away soon.
PiperOrigin-RevId: 643090275
Change-Id: I23470fa9e1efbcb42fa3866237038414545c7be2
There is no reason a temporary *shouldn't* be usable with BitGenRef (indeed, ABSL_ATTRIBUTE_LIFETIME_BOUND should catch errors) and it is useful when passing a temporary bitgen as an input argument.
PiperOrigin-RevId: 642021132
Change-Id: I03e46f5f437e40a0c6225ea1f0361475a3501513
std::is_signed can't be specialized, so this actually lets through non-unsigned types where the types are not language primitives (i.e. it lets absl::int128 through). However, std::numeric_limits can be specialized, and is indeed specialized, so we can use that instead.
PiperOrigin-RevId: 636983590
Change-Id: Ic993518e9cac7c453b08deaf3784b6fba49f15d0
`absl::int128` and `absl::uint128` are not `std::is_integral`. There is an internal `IsIntegral` type trait we could use, but it actually makes more sense to remove the `static_assert` altogether. Any compile-time validation should be done in `absl::Uniform` itself, and duplicating that logic here just increases the chance of divergence.
PiperOrigin-RevId: 635971431
Change-Id: I9177ae64c86ee1abe6571e0b29aba1844553c972
`absl::Uniform(tag, rng, a, b)` has some restrictions on the values it can produce in that it will always be in the range specified by `a` and `b`, but these restrictions can be violated by `absl::MockingBitGen`. This makes it easier than necessary to introduce a bug in tests using a mock RNG.
We can fix this by making `MockingBitGen` emit a runtime error if the value produced is out of bounds.
Immediately fixing all the internal buggy uses of `MockingBitGen` is currently infeasible, so the plan is this:
1. Add turned-off validation to `MockingBitGen` to avoid the costs of maintaining unsubmitted code.
2. Temporarily migrate the internal buggy use cases to keep the current behavior, to be fixed later.
3. Turn on validation for `MockingBitGen`.
4. Fix the internal buggy use cases over time.
---
A few of the different categories of errors I found:
- `Call(tag, rng, a, b) -> a or b`, for open/half-open intervals (i.e. incorrect boundary condition). This case happens quite a lot, e.g. by specifying `absl::Uniform<double>(rng, 0, 1)` to return `1.0`.
- `Call(tag, rng, 0, 1) -> 42` (i.e. return an arbitrary value). These may be straightforward to fix by just returning an in-range value, or sometimes they are difficult to fix because other data structures depend on those values.
PiperOrigin-RevId: 635503223
Change-Id: I9293ab78e79450e2b7b682dcb05149f238ecc550
