The Fuchsia team has been using either fork branches
(https://fuchsia.googlesource.com/third_
party/github.com/google/googletest/+/refs/heads/sandbox/fuchsia_bazel_sdk)
or patch files
(https://cs.opensource.google/fuchsia/fuchsia/+/main:build/bazel/patches/googletest/fuchsia-support.bundle)
to support googletest-based tests that run against a Fuchsia target device.
As our SDK is maturing and @platforms//os:fuchsia constraint has been added
for a while now, upstream Fuchsia gtest support to reduce technical debt and
overhead.
This change is noop for non-fuchsia platform builds.
PiperOrigin-RevId: 606843739
Change-Id: I61e0eb9c641f288d7ae57354fc0b484fce013223
_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
