This function makes exact floating point that are correct in this context, but trigger the compiler warning.
PiperOrigin-RevId: 596944060
Change-Id: I4bba3c2abcf3ac189107530978961955ad47d6f0
TSAN identified a data race between updates to the states_ map (ex. in Mock::UnregisterLocked) and the iteration done in this destructor. Writes to the map use g_gmock_mutex, but the destructor does not acquire it. Acquiring the lock here fixes the data race.
It should only be possible to trigger this TSAN finding in cases where a mock object is deleted by a thread other than the main thread.
PiperOrigin-RevId: 591935393
Change-Id: I9dd1faa40058d78e165a91333346514b4b73365c
`FAIL_AT` is shorthand for `GTEST_FAIL_AT` like `FAIL` is for `GTEST_FAIL`.
PiperOrigin-RevId: 590393926
Change-Id: I68263af8fa2f98ca0bbef509d475c84e22068018
`GetAbsolutePathToOutputFile` returns a `std::string` and `OpenFileForWriting`
takes a `std::string&`.
PiperOrigin-RevId: 589984409
Change-Id: I75be9cb105f49b3a279a5d33b1b82dfcfc912cfd
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
gmock.h is the umbrella header to be used for rest of the library, and it also
enables users to export certain details. This wasn't working for some interfaces
like EXPECT_CALL because gmock-spec-builders wasn't explicitly exported.
PiperOrigin-RevId: 576966583
Change-Id: Ie050430cf11384977cd95f4ed6e73235d6857057
If SIGTRAP is defined, this file may end up using raise(3), which is
defined in csignal, leading to a compilation failure on at least
OpenBSD/sparc64 with gcc 8.
The current implementation breaks for absl::string_view on gcc, c++14: https://godbolt.org/z/Tzd3q1fqxCloses#4391
PiperOrigin-RevId: 575853981
Change-Id: I7b782598add480eb69d4ca27ea4a4bf5f758f6a3
These are not used anywhere in googletest and they are in namespace `testing::internal`
PiperOrigin-RevId: 574171727
Change-Id: I5f668157a81ba3efaed77c1302b40cf07eeda52b
This is a somewhat recent change for Android (I'm not clear on whether it's a recent change for NetBSD, or if Android was just very behind on its implementation), so while this worked fine as recently as API 32 devices, REG_GNU is required for API 34 (API 33 untested).
A test actually caught this, but https://github.com/google/googletest/pull/4334 "fixed" the test rather than the implementation. This CL also reverts the test change so it can catch the failure.
PiperOrigin-RevId: 571126374
Change-Id: I420dfcedea58f2c8b605f699515d744006c0a9d9
The requirement is vaguely documented by "Only the return value of the last action in the sequence will be used.".
However, this can be misleading, as users could potentially expect default-constructed values to be returned in absence of a matching return type.
PiperOrigin-RevId: 570450839
Change-Id: Ibd98a6e6b2aaf2a8cfc15ed6aeab442526eab98e
This also avoids conflating C++ language versions with standard library versions, which don't always align.
PiperOrigin-RevId: 567662118
Change-Id: I7c023bd043c81c540c9430eaeb7b450feaadb206
Template type int changed to size_t.
This fixes compile warning `conversion to ‘long unsigned int’ from ‘int’ may change the sign of the result` in gmock-function-mocker.h.
* These long-dead variants of the proto matchers don't exist in the current version of Googletest.
* No evidence of external usage: [the only external references I see](https://www.google.com/search?q=%22protocolmessageequals%22+OR+%22protocolmessageequals%22) are copies of this guide. Possibly they were already removed by the time Googletest was publicly released.
PiperOrigin-RevId: 565358401
Change-Id: I61379b7333fa8ee19cd5520caedf2c539f54c2d7
The `Mutex` is locked with the `MutexLock` before spawning the thread, so that the thread is prevented from completing (by being blocked on `Mutex`) before the new thread count is obtained. However, the existing bug (introduced in 22e6055) releases `Mutex` before obtaining the new thread count, which allows the thread to run to completion in the meantime.
Also, since the `(thread_count_after_create != starting_count + 1)` condition (line 328) skips the remainder of the `for`-loop body on every iteration, `thread_count_after_join` stays uninitialized.
I believe this is why [this test failed][1] on the macOS CI with this trace:
```
[----------] 1 test from GetThreadCountTest
[ RUN ] GetThreadCountTest.ReturnsCorrectValue
googletest/test/googletest-port-test.cc:350: Failure
Expected equality of these values:
thread_count_after_create
Which is: 1
starting_count + 1
Which is: 2
googletest/test/googletest-port-test.cc:351: Failure
Expected equality of these values:
thread_count_after_join
Which is: 140493185949400
starting_count
Which is: 1
[ FAILED ] GetThreadCountTest.ReturnsCorrectValue (2 ms)
[----------] 1 test from GetThreadCountTest (2 ms total)
```
[1]: https://github.com/google/googletest/actions/runs/6064919420/job/16453860690?pr=3049
The following are the major updates
* LLVM 17 branch (https://github.com/llvm/llvm-project b744f4c99cf91155c74a3c92db6f1335232ff3d)
* GCC 13.2
* CMake 3.27.1
* Bazel 6.2.1
PiperOrigin-RevId: 558818264
Change-Id: Ib08d8331e2a8b2d68a702670451beaaac5d266f4
