Fix matcher comparisons for std::reference_wrapper.
The googletest docs indicate that std::reference_wrapper should be used to for
objects that should not be copied by the matcher (in fact, the ByRef() function
is basically the same as a call to std::cref).
However, for many types (such as std::string), the overloaded operator== will
not resolve correctly. Specifically, this is problematic if operator== depends
on template argument deduction, where the same type is named on LHS and RHS.
Because template argument deduction happens before any implict conversions for
purposes of overload resolution, attempting to compare T with
std::reference_wrapper<T> simply looks like a comparison of unlike types.
For exapmle, std::reference_wrapper<std::string> is implicitly convertible to
'const std::string&', which would be able to choose an overload specialization
of operator==. However, the implicit conversion can only happen after template
argument deduction for operator==, so a specialization that would other be an
applicable overload is never considered.
Note also that this change only affects matchers. There are good reasons that
matchers may need to transparently hold a std::reference_wrapper. Other
comparisons (like EXPECT_EQ, et. al.) don't need to capture a reference: they
don't need to defer evaluation (as in googlemock), and they don't need to avoid
copies (as the call chain of matchers does).
PiperOrigin-RevId: 232499175
When building and using googletest from an install tree
we want libtool to generate rpath in the dependent binaries
to allow them to be executed from a build without a need
for LD_LIBRARY_PATH or similar.
For libtool based project this happens automatically
as projects generates .la files and install them.
Provide such a file for gtest as well to allow it to
work smoothly with libtool based projects.
Signed-off-by: Knut Omang <knut.omang@oracle.com>
This is just a mistake in the document. Google Test doesn't output
such an invalid JSON report.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
This will help ensure that test coverage isn't missed when changes that
can impact OSX with clang are submitted. Although not perfect, testing
changes on OSX with clang is an ok proxy [for now] for testing changes on
FreeBSD with clang (testing on FreeBSD is non-trivial, as Travis CI doesn't
support operating systems other than Linux and OSX).
In order to support this, install the packages via homebrew using a
`addons::homebrew::packages` block (similar to `addons::apt::packages`
for Ubuntu), as documented in the Travis CI docs
( https://docs.travis-ci.com/user/installing-dependencies/ ). While
here, try pushing apt* calls into the Travis config for Ubuntu, instead
of delaying the equivalent calls in the `ci/*.sh` scripts. Keep the
`ci/*.sh` scripts for ease of testing locally (and extend the OSX one to
install gcc 4.9 and llvm 3.9, like the travis config does).
In order to accomodate this change (and because the homebrew package for
llvm@3.9 doesn't automatically add clang*-3.9 to `$PATH`), `$PATH` needs
to be adjusted to find the llvm@3.9 toolchain.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
Address -Wgnu-zero-variadic-macro-arguments
Originally in OSS PR #2063https://github.com/google/googletest/pull/2063
Fix regression in INSTANTIATE_TEST_SUITE_P macro to accept function pointers properly.
PiperOrigin-RevId: 232316698
I made a few updates to the Makefile.am files so that "make dist"
succeeds and produces a usable tarball. We need this for protobuf
because the protobuf tarballs include a bundled copy of googletest.
Add AllOfArray matcher that verifies a value matches all member of some array/container/list/set/..., e.g:
EXPECT_THAT(1, AnyOfArray({1, 2, 3}))
In the simplest form this is identical to AnyOf(1, 2, 3). But unlike that one it works on containers.
Add AnyOfArray matcher that verifies a value matches any member of some
array/container/list/set/...
PiperOrigin-RevId: 230403653
