| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
`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
|
|
|
--
4503a1945d61540d3f7dd9ee2399297fbd423b82 by Andy Soffer <asoffer@google.com>:
Releasing absl::MockingBitGen and absl::BitGenRef
PiperOrigin-RevId: 281594380
--
2cb926fd9e39b5fa24c9541bfafcf18916cf7df2 by Abseil Team <absl-team@google.com>:
Explicitly export files needed by other packages
PiperOrigin-RevId: 281482304
GitOrigin-RevId: 4503a1945d61540d3f7dd9ee2399297fbd423b82
Change-Id: Id9f694eaaa23f42de817c8e8a28e6f86444f5637
|
