| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
PiperOrigin-RevId: 651258120
Change-Id: I1c343bc11407d33dc2d0bb1686be4bdbe6a600df
|
|
|
|
|
| |
PiperOrigin-RevId: 646105357
Change-Id: Ia76c1ce33faf811e988d36747f187c112ccb967e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 636992927
Change-Id: I4da3be41a5961d0828eec7ac5c67b299a2e0f237
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 630047753
Change-Id: I6ad73216bbe4e279553b9a57bd2727310091c754
|
|
|
|
|
|
|
|
|
| |
It took me way too much time to figure out why parameters of `absl::LogUniform` have nothing to do with the contents of the linked wiki page.
The new link does not match the function exactly, but it is still much closer than the log-normal distribution.
PiperOrigin-RevId: 619749575
Change-Id: Idbe748ed0dadf3ca22dc592f296f770ce04de8be
|
|
|
|
|
| |
PiperOrigin-RevId: 616083064
Change-Id: I3d69303d32431227c197247682f8dcb70f9a239d
|
|
|
|
|
|
|
| |
BasicMocking.MocksNotTriggeredForIncorrectTypes test.
PiperOrigin-RevId: 615030645
Change-Id: Ia0ff3e649c6155c44d4772ce32fbcd4c5b273cc7
|
|
|
|
|
| |
PiperOrigin-RevId: 611151721
Change-Id: Ic7b342770fb3e1aab8e54ff125f1529534eedc3c
|
|
|
|
|
|
|
| |
in 146169f9ad357635b9cd988f976b38bcf83476e3) with fix.
PiperOrigin-RevId: 604534265
Change-Id: Ic70ae72d4d73ac8849196cb844c8de32790bd6c8
|
|
|
|
|
| |
PiperOrigin-RevId: 603696164
Change-Id: I876ae0ead5964b626c285c60d9a4b2bbe62e113d
|
|
|
|
|
| |
PiperOrigin-RevId: 603576688
Change-Id: I5e7868de7016d76fb7a44fea93be72ab90f239d3
|
|
|
|
|
|
|
| |
https://bazel.build/build/style-guide#other-conventions
PiperOrigin-RevId: 603084345
Change-Id: Ibd7c9573d820f88059d12c46ff82d7d322d002ae
|
|
|
|
|
| |
PiperOrigin-RevId: 572575394
Change-Id: Ic1c5ac2423b1634e50c43bad6daa14e82a8f3e2c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The layering_check feature ensures that rules that include a header
explicitly depend on a rule that exports that header. Compiler support
is required, and currently only Clang 16+ supports diagnoses
layering_check failures.
The parse_headers feature ensures headers are self-contained by
compiling them with -fsyntax-only on supported compilers.
PiperOrigin-RevId: 572350144
Change-Id: I37297f761566d686d9dd58d318979d688b7e36d1
|
|
|
|
|
|
|
| |
This cl/ updates the link provided in the comment to point to a valid website. Currently the link points to https://screenshot.googleplex.com/BZhRp6mNJAtjMmz which is now a software company landing page.
PiperOrigin-RevId: 570384723
Change-Id: Ib6d17851046125957e092b59d845ddb7ecb1f7b7
|
|
|
|
|
| |
PiperOrigin-RevId: 541111597
Change-Id: I88165130e30e548a03d8d6173dadab33dc18b21e
|
|
|
|
|
|
|
|
|
|
|
| |
The non-RAW_ versions provide better output but weren't available when most of these tests were written.
There are just a couple spots where RAW_ is actually needed, e.g. signal handlers and malloc hooks.
Also fix a couple warnings in layout_test.cc newly surfaced because the optimizer understands CHECK_XX differently than INTERNAL_CHECK.
PiperOrigin-RevId: 534584435
Change-Id: I8d36fa809ffdaae5a3813064bd602cb8611c1613
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/1452
__cpuid is declared in intrin.h, but is excluded on non-Windows platforms.
We add this declaration to compensate.
Fixes #1358
PiperOrigin-RevId: 534449804
Change-Id: I91027f79d8d52c4da428d5c3a53e2cec00825c13
|
|
|
|
|
| |
PiperOrigin-RevId: 534213948
Change-Id: I56b897060b9afe9d3d338756c80e52f421653b55
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 534179290
Change-Id: I9ad24518cc6a336fbaf602269fb01319491c8b60
|
|/
|
|
|
|
|
|
| |
__cpuid is declared in intrin.h, but is "excluded" on non-Windows
platforms.
We add this declaration to compensate.
Fixes #1358
|
|
|
|
|
| |
PiperOrigin-RevId: 530999471
Change-Id: Ifca68cd53be629088244eaa3560d43fd81090747
|
| |
|
| |
|
| |
|
|
|
|
| |
This lets us avoid having to do the addition manually.
|
|
|
|
|
|
|
|
| |
This change fixes -Wimplicit-const-int-float-conversion warnings
by making the conversions explicit.
PiperOrigin-RevId: 520707623
Change-Id: Ib6917469120cd7458257195cbf39beb3fd397543
|
|
|
|
|
|
|
|
|
|
| |
Since the return value of `NumBits()` will always fit into `size_t`,
use an explicit cast to silence the implicit conversion warning.
Fixes #1384
PiperOrigin-RevId: 518041598
Change-Id: If2f2456db4b27b78e9ea9e026dce610953bd5bfb
|
| |
|
|
|
|
|
| |
PiperOrigin-RevId: 501644407
Change-Id: Ie98d22e4983cfbd9cad2176925774d624d4702cf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several problems with the previous documentation:
* It said it's stable "within the same binary" but not stable "across multiple binary invocations". Those statements contradict each other.
* It said "in the same binary will not produce the same sequence of variates within the same binary", which is repetitive since it says "in the same binary" twice.
* The comments about the seed sequence were not all next to each other, they were split apart by a rand.req.urng comment.
* It implied that process stability is all you get, whereas generally you also get changelist stability.
* It said you can use a seed sequence with SharedBitGen, but you can't.
* It said there is more info in std_seed_seq.h , but there isn't.
PiperOrigin-RevId: 501389708
Change-Id: I5e3dbc3548cc051265b8d004191c23147eccecc3
|
|
|
|
|
|
|
| |
See cl/490546476 for details.
PiperOrigin-RevId: 494047255
Change-Id: Ic2f88d976fa9a70ff104c47e9daf682ab7d0b7d2
|
|
|
|
|
| |
PiperOrigin-RevId: 488955034
Change-Id: I143f3632b295098bc6ea5c6aedf7446dd91c668b
|
|
|
|
|
| |
PiperOrigin-RevId: 488799458
Change-Id: I1aaaa60c5be3260055a6f5773f78cb4043a60ac8
|
|
|
|
|
| |
This corrects the generated .pc files, so these libs match the other libs
already included there.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL enables these warnings and fixes the remaining known issues.)
Bug: chromium:1292951
PiperOrigin-RevId: 480981210
Change-Id: I92d5023c6833e24d6aa29b10d433116329972f41
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in */internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 473868797
Change-Id: Ibe0b76e33f9e001d59862beaac54fb47bacd39b2
|
|
|
|
|
|
|
|
| |
In the time since pcg_engine.h was written, absl::uint128 was fixed to
generate identical code to __uint128_t
PiperOrigin-RevId: 471789541
Change-Id: Ibd1afc3e5e6d57af27cdd6a21171c96ea333161c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in */internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 471561809
Change-Id: I7abd6d83706f5ca135f1ce3458192a498a6280b9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in */internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 471549854
Change-Id: Id685d0e4666212926f4e001b8ef4930b6a33a4cc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in dirs n-t, except string.)
Bug: chromium:1292951
PiperOrigin-RevId: 465287204
Change-Id: I0fe98ff78bf3c08d86992019eb626755f8b6803e
|
|
|
|
|
|
|
|
|
|
|
| |
This test indicates it has a 90% chance of timing out at its current 60 second limit.
Stats over 1000 runs: max = 102.5s, min = 40.4s, avg = 71.1s, dev = 11.2s
Note that if you run this test locally from a workstation without flags, it'll take maybe 3 to 5 seconds. However, the test is run with config of android_arm, which seems to drastically change the execution time.
PiperOrigin-RevId: 459503103
Change-Id: I7b7aaa2db7880370f47d1a83d295a3234f738a18
|
|
|
|
|
| |
PiperOrigin-RevId: 455129922
Change-Id: I3b2a62cbf50057b3ea9b73c2edb44271dc46986c
|
|
|
|
|
| |
PiperOrigin-RevId: 454969441
Change-Id: Ic18d91243ed3aa661ebf47a4c0ea96057aa4092d
|
|
|
|
|
|
|
| |
A few targets were missing `linkopts = ...` and so were not obeying
the project-wide default settings.
Omit any changes to cctz for now, because it's vendored from another project.
|