_Exit is standardized since C99, whereas _exit is POSIX-only.
Fixes: #4447
PiperOrigin-RevId: 605000352
Change-Id: Ibfa84edaa043bd003a21383e8148bf45be7217f6
Destruction in static teardown causes issues for Environments which own threads and try to join them in their destruction.
This may be a breaking change for users who call RUN_ALL_TESTS multiple times in the same main function if they also install environments, or those who access registered environments after RUN_ALL_TESTS.
The easiest fix is to only call RUN_ALL_TESTS once as the last line of the main function. Another potential fix is to re-register new instances of the Environment once before each call to RUN_ALL_TESTS.
PiperOrigin-RevId: 604800795
Change-Id: I37c44d4aca4a238052649f45a4b6b9cfb5355b71
Stack traces in assertion failures are an extremely useful tool for
developers tasked with investigating failing tests. It's difficult to
understate this. In contrast to ordinary test assertions (e.g.,
ASSERT_TRUE or EXPECT_FALSE), SUCCEED() is a developer-authored
directive that indicates a success codepath. In fact, the documentation
states that this directive doesn't generate any output. Generating stack
traces for uses of SUCCEED() is wasted work since they are never
printed. If this were to change one day in the future, they still would
not be useful since any emitted message would include the file and line
number where SUCCEED was used. In addition to being noise in the output
in this case, symbolization of stack traces is not free. In some
Chromium configurations, symbolization for use of SUCCEED() can incur a
cost in excess of 25 seconds for a test that otherwise takes 0-1ms; see
https://crbug.com/1517343.
In this CL, we suppress generation and emission of stack traces for
kSuccess messages to reduce the overhead of SUCCEED().
PiperOrigin-RevId: 602832162
Change-Id: I557dd6a1d3e6ed6562daf727d69fd01fe914827b
Stack traces in assertion failures are an extremely useful tool for
developers tasked with investigating failing tests. It's difficult to
understate this. In contrast to ordinary test assertions (e.g.,
ASSERT_TRUE or EXPECT_FALSE), GTEST_SKIP is a developer-authored
directive to skip one or more tests. Stack traces emitted in skip
messages do not give the developer useful information, as the skip
message itself contains the code location where GTEST_SKIP was used. In
addition to being noise in the output, symbolization of stack traces is
not free. In some Chromium configurations, symbolization in a skipped
test can incur a cost in excess of 25 seconds for a test that otherwise
takes 0-1ms; see https://crbug.com/1517343#c9.
In this CL, we suppress generation and emission of stack traces for
kSkip messages to reduce the output noise and overhead of GTEST_SKIP().
PiperOrigin-RevId: 598899010
Change-Id: I46926fed452c8d7edcb3d636d8fed42cb6c0a9e9
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 `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
`TestNonHelpFlag` is only a few asserts with no logic, which is easier to read in line, and helper `TestHelpFlag` is used in a single test case.
PiperOrigin-RevId: 557122793
Change-Id: I7367424abfbb883c10c260fae066a2071e5dfa0e
The last regular expression specified in the test is not technically
POSIX compatible. Use `[[:alnum:]_]` instead of `\w+`; the latter is a
Perl-compatible regular expression.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
The test supported a variety of BSDs, including kFreeBSD, but not FreeBSD.
Move the BSD checks to a separate function and support checking for
FreeBSD, in addition to kFreeBSD.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
This allows types that provide an AbslStringify definition to be streamed into GoogleTest macros.
PiperOrigin-RevId: 552914482
Change-Id: I5fb386980d4d24873f95f0a8ef83067a6a3c86ac
This is useful for running individual tests in a separate process, which is
useful for testing e.g. flag changes which have a process-global effect.
PiperOrigin-RevId: 540580573
Change-Id: I18a5d24d79425a9d595be3369efc44e2f655f6f8
This change brings InitGoogleTest semantic in accordance with the official documentation: only GoogleTest flags are removed from argc/argv. The rest of the flags remains in place. We do nothing special for flags with unrecognized gunit_/gtest_ prefix and we do not report them.
PiperOrigin-RevId: 527257221
Change-Id: Ibb29a1bda1a44251a4ee579c0fb5bbdfd9965c21
This seems to just have been an oversight. POSIX socket APIs work just
fine on macOS.
Fixes https://github.com/google/googletest/issues/4214.
PiperOrigin-RevId: 523398386
Change-Id: I9d56cd9c6933318c1f0b0024f7fef44122fd0c83
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
For MSVC, gmock_output_test.py output struct std::pair<int,bool>, for GCC, it's output
std::pair<int, bool>, it's not the same, my intention is getting these to be same by removing
struct for MSVC's outptu, and strip redundant space for GCC.
As a by-product,
```
#ifdef _MSC_VER
#define ERROR_DESC "class std::runtime_error"
#else
#define ERROR_DESC "std::runtime_error"
#endif
```
can be simplified to
```
#define ERROR_DESC "std::runtime_error"
```
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Historically, calls to RecordProperty with values that are convertible to
int64_t have been casted to int64_t. The result was that types like float or
double would be truncated when printed (e.g., 4.75 -> 4). This change removes
the cast so that the types are printed in a more appropriate manner.
PiperOrigin-RevId: 511238685
Change-Id: I80de5db14462da2a3e1f476086025ae514383a17
