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
* Applies for `std::index_sequence`, `std::make_index_sequence`, and `std::index_sequence_for` replacing `IndexSequence`, `MakeIndexSequence` and IndexSequenceFor`
* Also deleted implementation helper `DoubleSequence`
* The standard interfaces [have been in the standard library since C++14](https://en.cppreference.com/w/cpp/utility/integer_sequence), which [is the minimum supported C++ version by Google Test](https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md)
PiperOrigin-RevId: 621939977
Change-Id: Id264266f08da66c0fa2a6e6fbb8f86fd3cb3a421
We avoid overloading or specializing `testing::Throw` as this is fundamentally a different operation than throwing the object.
However, we disable the corresponding overload of `testing::Throw` to prevent likely mistakes in the usage.
Fixes: #4412
PiperOrigin-RevId: 585745469
Change-Id: I03bb585427ce51983d914e88f2bf65a13545c920
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
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
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
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
Avoid instantiating functions like std::get<index> for an out of range index
when doing SFINAE on the invocability of the action itself.
PiperOrigin-RevId: 439415110
Change-Id: Ifc20285a6d526c34830870cd1910c2b2b92e1e81
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
This catches when a client creates an action and discards it, thinking that the action has actually been applied to something.
This will help people who make the mistake of defining, for example, both `void Use(Foo*, Bar)` and `ACTION_P(Use, bar) { Use(arg, bar); }` for later application to a Foo. With such an overload, a client may then write `Use(bar);`, selecting the Action<> overload and being confused why nothing happens.
This also catches when a client defines their own action in terms of an ACTION_P()-generated one, invokes the Action<>'s builder, and then fails to invoke the resulting action, thinking it's operating on the outer action's parameters.
PiperOrigin-RevId: 433197479
Change-Id: I98e4389150d01a5e753230113016d9fc38b1d260
Update stale links to `gmock_cook_book.md`.
I'm a new googletest user and found these links broken when reading the documentation.
PiperOrigin-RevId: 357786392
Change ACTION{,_Pn,_TEMPLATE} macros to build functors rather than ActionInterface<> subclasses, thus changing the Action<> wrappers they create to use the modernized (non-const) argument tuple type, allowing these macros to mutate their arguments.
Functor-based Action<>s deep-copy the implementing object, so have the functors use a shared_ptr to the non-trivial state of bound value parameters. No longer specialize that shared state to the particular action signature, encoding that information instead only in the instantiation of the implementation function.
PiperOrigin-RevId: 341116208
Mark ACTION_Pn()-generated functions as must-use-result.
This catches when a client creates an action and discards it, thinking that the action has actually been applied to something.
This will help people who make the mistake of defining, for example, both `void Use(Foo*)` and `ACTION(Use) { Use(arg); }` for later application to a Foo. With such an overload, a client may then write `Use();`, forgetting the param and being confused why nothing happens.
This also catches when a client defines their own action in terms of an ACTION()-generated one, invokes the ACTION's builder, and then fails to invoke the resulting action, thinking it's operating on the outer action's parameters.
PiperOrigin-RevId: 330614454
Replace uses of ACTION_TEMPLATE and ACTION_P with manually written functors.
The latter provide better error diagnostics.
This fixes https://github.com/google/googletest/issues/2729.
PiperOrigin-RevId: 328573022
Workaround static assert in early versions libc++
The error is "Attempted to construct a reference element in a tuple with an
rvalue". We can fix this by putting everything into a non temporary tuple_args
and implitly convert to the other tuple types. This avoids binding an rvalue
reference to an lvalue reference inside the tuple.
PiperOrigin-RevId: 327624990
Fix DoAll to work with move-only sink arguments.
This changes types of the first n - 1 actions so that they only get a readonly
view of the arguments. The last action will accept move only objects.
PiperOrigin-RevId: 327031893
Fix DoAll to work with move-only sink arguments.
This changes types of the first n - 1 actions so that they only get a readonly
view of the arguments. The last action will accept move only objects.
PiperOrigin-RevId: 324619666
Fix DoAll to work with move-only sink arguments.
This changes types of the first n - 1 actions so that they only get a readonly
view of the arguments. The last action will accept move only objects.
PiperOrigin-RevId: 324600664
Mark ACTION_Pn()-generated functions as must-use-result.
This catches when a client creates an action and discards it, thinking that the action has actually been applied to something.
This will help people who make the mistake of defining, for example, both `void Use(Foo*)` and `ACTION(Use) { Use(arg); }` for later application to a Foo. With such an overload, a client may then write `Use();`, forgetting the param and being confused why nothing happens.
This also catches when a client defines their own action in terms of an ACTION()-generated one, invokes the ACTION's builder, and then fails to invoke the resulting action, thinking it's operating on the outer action's parameters.
PiperOrigin-RevId: 312108101
Aaron Jacobs
Derek Mauro
Lawrence Wolf-Sonkin
Abseil Team
Robert Shade
Tom Hughes
assafpr
Dino Radakovic
ofats