Make EXPECT_THROW print the actual exception type on the "threw the wrong exception type" case if the actual exception is a std::exception
PiperOrigin-RevId: 211524592
Make EXPECT_THROW print the actual exception type on the "threw the wrong exception type" case if the actual exception is a std::exception
PiperOrigin-RevId: 211519873
Fix Clang warning:
| warning: definition of implicit copy constructor for 'ValueArray2<bool, bool>'
| is deprecated because it has a user-declared copy assignment operator [-Wdeprecated]
Commit 6a26e47cfc changed the formatting
of INSTANTIATE_TEST_CASE_P() in the generated header file only.
This commit reverts to the formatting produced by running "pump
gtest-param-test.h.pump", which seems to be more consistent with the
rest of the file.
Fix the typed test names in the tests for customized typed test parameters.
As required by googletest documentation, the names should not contain an underscore.
PiperOrigin-RevId: 210678652
Fix line that was wrapping in the middle of a link
This looks uglier, but has the advantage that the link is kept in one
piece.
PiperOrigin-RevId: 210537337
Add the possibility of specifying the name in type parameterized tests.
Similar to how the last parameter of INSTANTIATE_TEST_CASE_P allows to override the name for (non-type) parametrized tests, this adds the possibility of adding a parameter to INSTANTIATE_TYPED_TEST_CASE_P. The argument has to be a class, which contains a static templated function GetName<T>(int), returning the name for type T.
PiperOrigin-RevId: 210532231
Fix Theta(N^2) memory usage of EXPECT_EQ(string) when the strings don't match.
The underlying CalculateOptimalEdits() implementation used a simple
dynamic-programming approach that always used N^2 memory and time. This meant
that tests for equality of large strings were ticking time bombs: They'd work
fine as long as the test passed, but as soon as the strings differed the test
would OOM, which is very hard to debug.
I switched it out for a Dijkstra search, which is still worst-case O(N^2), but
in the usual case of mostly-matching strings, it is much closer to linear.
PiperOrigin-RevId: 210405025
