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
When checked out on Windows, the repo might use \r\n line endings,
and so the golden output has them. Adjust for that.
PiperOrigin-RevId: 502577222
Change-Id: Iabfe537f6d95a49bf6bdcb934e855d28c65f6f89
MatcherDescriberInterface specifies that DescribeTo "should print a verb phrase", but "size ..." is not a verb phrase. Currently, ElementsAre(SizeIs(9)) is described as "has 1 element that size is equal to 9". With this change, it will be described as "has 1 element that has a size that is equal to 9".
PiperOrigin-RevId: 492022324
Change-Id: I4083335f2419462464957521c1e033643b53b763
Do this by ripping out the "untyped perform action" machinery, which isn't
necessary: we can simply template the entry point on the result type, and use
RAII to avoid the need to special case void. This makes it easier to understand
the code and harder to introduce type-related undefined behavior, to boot.
PiperOrigin-RevId: 451493451
Change-Id: I225305f83164752ca92f2916721972eafba33168
Previously this excluded callables that return non-moveable types. This is the
same as the
[libc++ std::is_invocable_r bug](https://github.com/llvm/llvm-project/issues/55346)
fixed by
[this commit](https://github.com/llvm/llvm-project/commit/c3a24882903d): it's
wrong to use std::is_convertible for checking the return type, since (despite
its name) that doesn't check the standard-defined notion of "implicitly
convertible". Instead we must base the check on whether the source type can be
used as an argument to a function that accepts the destination type.
PiperOrigin-RevId: 451341205
Change-Id: I2530051312a0361ea7a2ce26993ae973c9242089
`Return(x)` can now be used directly with `WillOnce` (the only place it makes
sense in the type system), without using `ByMove`.
PiperOrigin-RevId: 448380066
Change-Id: Ia71cc60ccbc3b99720662731a2d309735a5ce7c8
It doesn't make semantic sense for the conversion to modify the input, and the
fact that it's allowed to do so appears to have just been a historical accident.
PiperOrigin-RevId: 448135555
Change-Id: Id10f17af38cf3947ee25fe10654d97527173ebfc
Better document requirements, API decisions, and historical accidents. Make an
implicit conversion easier and in a more appropriate place, and ease the burden
of some assertions in the conversion operator. Stop using the legacy
ActionInterface style for defining the action.
PiperOrigin-RevId: 447894892
Change-Id: I179e23ec2abdd9bf05c204ab18dbb492f1372e8e
So that it can be referenced in conversion operators for actions that need to
know the concrete return type.
PiperOrigin-RevId: 447889344
Change-Id: I643d3298bc8effd08741282a956c221f9d67d378
Commit a070cbd91c added an implicit cast to this path but didn't leave a very
clear explanation for why it was desirable, a clear example, or even test
coverage. Add a better comment and a test that fails when the implicit cast is
removed.
PiperOrigin-RevId: 444871311
Change-Id: I127982fa8d5bce9b6d1b68177c12dc0709449164
This is necessary for generic support of these actions, since `DoAll` is a
frequently-used action wrapper.
PiperOrigin-RevId: 444561964
Change-Id: I02edb55e35ab4207fbd71e371255a319c8253136
This provides a type-safe way for an action to express that it wants to be
called only once, or to capture move-only objects. It is a generalization of
the type system-evading hack in ByMove, with the improvement that it works for
_any_ action (including user-defined ones), and correctly expresses that the
action can only be used with WillOnce. I'll make existing actions benefit in a
future commit.
PiperOrigin-RevId: 440496139
Change-Id: I4145d191cca5655995ef41360bb126c123cb41d3
The one large test does not link in limited memory environments
Closes#3653
PiperOrigin-RevId: 436753193
Change-Id: Idd59b6509994fc642147b88279ee791cd1d7bdd0
A few tests are examining code locations and looking af the resulting line
numbers to verify that GoogleTest shows those to users correctly. Some of those
locations change when clang-format is run. For those locations, I've wrapped
portions in:
// clang-format off
...
// clang-format on
There may be other locations that are currently not tickled by running
clang-format.
PiperOrigin-RevId: 434844712
Change-Id: I3a9f0a6f39eff741c576b6de389bef9b1d11139d
unifying the behavior between Bazel and CMake
This fixes one of the CI failures on Windows
PiperOrigin-RevId: 417872531
Change-Id: I156989323b7e6d4a4420f4f9691b078829db933d
The previous error message could be misinterpreted to mean that `Times` could not be
used in combination with `WillRepeatedly`, when in fact the call to `Times` just needs to happen *first*.
PiperOrigin-RevId: 410070405
Change-Id: I747d34a4334cf2e56d589dcad3a08a8f322d77c8
