For `EXPECT_THAT` matcher usage, showing only the first failure meant
that users would sometimes have to make a fix and run the test again
only to notice that there's another failure. It's better to show more
failures so that the user can fix several issues in one go.
In practice, very little code actually wants the short circuiting here,
only a handful of cases with custom matchers used like
`AllOf(BoundsCheck(), UncheckedAccess())`. These cases are fixable by
refactoring `UncheckedAccess()` to instead also apply a bounds check to
fail the matcher rather than crash. Notably, this change doesn't affect
`AnyOf`, so another workaround is to change `AllOf(m1, m2, ...)` into
`Not(AnyOf(Not(m1), Not(m2), ...))`.
PiperOrigin-RevId: 826316273
Change-Id: Ie8186f75c10443d8da35b5d07b6a8cd9ae85b451
`std::abs()` doesn't work on custom types. While one can use the 3-argument version of `DistanceFrom()` to specify how to compute the distance, it's not as convenient as defining `abs()` for the custom type once in the type's namespace and then use the 2-argument version.
PiperOrigin-RevId: 735741409
Change-Id: If8fb668455eb963a2ccf089f7467c64965a2e7a6
We have a bunch of matchers for asserting that a value is near the target value, e.g.
`DoubleNear()` and `FloatNear()`. These matchers only work for specific types (`double` and `float`). They are not flexible enough to support other types that have the notion of a "distance" (e.g. N-dimensional points and vectors, which are commonly used in ML).
In this diff, we generalize the idea to a `DistanceFrom(target, get_distance, m)` matcher that works on arbitrary types that have the "distance" concept (the `get_distance` argument is optional and can be omitted for types that support `-`, and `std::abs()`). What it does:
1. compute the distance between the value and the target using `get_distance(value, target)`; if `get_distance` is omitted, compute the distance as `std::abs(value - target)`.
2. match the distance against matcher `m`; if the match succeeds, the `DistanceFrom()` match succeeds.
Examples:
```
// 0.5's distance from 0.6 should be <= 0.2.
EXPECT_THAT(0.5, DistanceFrom(0.6, Le(0.2)));
Vector2D v1(3.0, 4.0), v2(3.2, 6.0);
// v1's distance from v2, as computed by EuclideanDistance(v1, v2),
// should be >= 1.0.
EXPECT_THAT(v1, DistanceFrom(v2, EuclideanDistance, Ge(1.0)));
```
PiperOrigin-RevId: 734593292
Change-Id: Id6bb7074dc4aa4d8abd78b57ad2426637e590de5
Prior to this change we had a mixture of pragmas and
GTEST_DISABLE_MSC_WARNINGS; this change consolidates all instances
to use the macros.
PiperOrigin-RevId: 505786926
Change-Id: I2be8f6304387393995081af42ed32c2ad1bba5a7
In #4113 a user says Max clashes with a macro. Since it is only used in
a test, use std::numeric_limits::max() instead.
Note that in headers, the macro issue can be mitigated with
parenthesis like this: `(std::numeric_limits<T>::max)()`
PiperOrigin-RevId: 504284906
Change-Id: Ibf430caec1a6afdf6b303534fec6a4fd00a6373f
The one large test does not link in limited memory environments
Closes#3653
PiperOrigin-RevId: 436753193
Change-Id: Idd59b6509994fc642147b88279ee791cd1d7bdd0
