In particular this automatically gives us support for examples like the
following:
using SomeFn = absl::AnyInvocable<R(Args...) const>;
MockFunction<SomeFn> some_fn;
PiperOrigin-RevId: 921303527
Change-Id: I19bf59671781e85db65cc20c0d6ea10b056c528a
Currently it will refuse to become a `OnceAction` if its component sub-actions
have an `Action` conversion operator but don't know about `OnceAction` in
particular because although `Action` is convertible to `OnceAction`, the
compiler won't follow the chain of conversions.
Instead, teach it explicitly that it can always be a `OnceAction` when it can be
an `Action`.
PiperOrigin-RevId: 655393035
Change-Id: Ib205b518ceef5f256627f4b02cd93ec9bd98343b
Ensure that tests are run in the order specified in the source code, even if
they are registered manually using RegisterTest. There should be no behavior
change for the common case.
PiperOrigin-RevId: 520729483
Change-Id: I400c78400c6929fccae0676214d993251f31888f
This makes the behavior consistent when GTEST_STACK_TRACE_DEPTH is set to zero
and not: there is always vertical whitespace separating failure messages.
PiperOrigin-RevId: 518744611
Change-Id: I5b4af40633849850660504c3f497a76601d4311d
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
In order to make the diff more readable in an upcoming commit that requires the
method to be templated on the action's result type.
PiperOrigin-RevId: 451157029
Change-Id: I57beb7544efccd0459efb3a1f039ea45cd7c7602
`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
Rather than branching on whether the return type is ByMoveWrapper within
ReturnAction itself, hoist the distinction to outside. This allows the main
class template to be modified without worrying about this special case, which
means we can stop using a shared pointer to the value (introduced as a
linked_ptr in commit 3d1c78b2bf to support ByMove) in this commit and simplify
the class template further in a future commit with the eventual aim of directly
supporting move-only result types.
PiperOrigin-RevId: 445938943
Change-Id: I7bc71ea301d5e493ac6ecbe57d62738a48a2721a
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
Aaron Jacobs