GitLab

According to the 2nd point on [1], -lregex is required on QNX.

[1] https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.ide.userguide/topic/writing_test_programs.html

On QNX, pthread is part of libc [1]. There's no separate pthread library
to link.

[1] https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.lib_ref/topic/p/pthread_create.html

Remove the dependency on Objective C++ in iOS builds.

252ce9c5 introduced the use of
NSTemporaryDirectory() on iOS, which requires Core Foundation, and
Objective C++.

This CL replaces NSTemporaryDirectory() with an equivalent solution
(according to Apple's documentation at [1]) available to C/C++ code.
Avoiding Objective C++ and Core Foundation makes it easier to integrate
googletest in projects that can't use the supplied Bazel build files.

[1] https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html#//apple_ref/doc/uid/TP40002585-SW10

PiperOrigin-RevId: 375474990

Fix iOS logging issues in tests

PiperOrigin-RevId: 370484087

Print std::u8string, std::u16string, and std::u32string as string literals

Previously, these types were printed as "{ U+123, U+456, U+789 }". However,
printed output in that form is difficult to compare against any literals that
might be defined in code. Instead, just treat these types like std::string
and std::wstring, escaping non-ASCII characters with a hexadecimal escape
sequence.

The tests have also been updated to cover the new functionality: as a bonus,
the tests now also pass with the MSVC toolchain.

Internally, the code has been reorganized to primarily operate in terms of
char32_t, under the assumption that char32_t will always be at least as big
as wchar_t. While that assumption is currently true, perhaps it won't be in
the future...

PiperOrigin-RevId: 364033132

This makes it easier to include the license in redistributions, as required by the license.

Fixes googletest for upcoming `--incompatible_load_cc_rules_from_bzl` (https://github.com/bazelbuild/bazel/issues/8743) and `--incompatible_load_python_rules_from_bzl` (https://github.com/bazelbuild/bazel/issues/9006).

This change was automatically generated with `buildifier -lint=fix -warnings=all $(find . -name "BUILD" -o -name "BUILD.bazel" -o -name "*.bzl")`.

Internal Change

PiperOrigin-RevId: 245788057

Signed-off-by: Pavel Samolysov <samolisov@gmail.com>

While the google test library is being built as a shared library using Bazel,
so that there is a rule like

cc_test(
     name = "iterator_traits_test",
     linkstatic = 0,
     deps = ["@gtest//:gtest_main"],
     ...
)

in a BUILD file, the following error appears on Windows:

INFO: Found 1 test target...
ERROR: C:/../external/gtest/BUILD.bazel:55:1: output 'external/gtest/gtest.if.lib' was not created
ERROR: C:/../external/gtest/BUILD.bazel:55:1: not all outputs were created or valid
Target //test:iterator_traits_test failed to build

The reason is a missing "win_def_file" attribute of the "gtest" and
"gtest_main" rules in the BUILD.bazel inside the google test library
package.

The "windows_export_all_symbols" feature is added to the rules, this
feature forces Bazel to export all symbols from the google test library
to linker. I believe exporting all symbols from a testing library makes
no problem for the application from a point of view on encapsulation.
Signed-off-by: Pavel Samolysov <samolisov@gmail.com>

Fix bazel issue

PiperOrigin-RevId: 223829127

Fix bazel issue

PiperOrigin-RevId: 223823930

Improve Bazel build files.

New target gtest_prod allows access to the FRIEND_TEST macro without depending on the entirety of GTest in production executables. Additionally, duplicate config_setting rules were removed and formatting was adjusted.

PiperOrigin-RevId: 220279205

Internal Change

PiperOrigin-RevId: 215236414

Add myself to the authors table.

PiperOrigin-RevId: 214822035

This change adds the ability to generate stacktraces in Google Test on
both failures of assertions/expectations and on crashes. The
stacktrace support is conditionally available only when using Abseil
with Google Test.

To use this support, run the test under Bazel with a command like this:

bazel test --define absl=1 --test_env=GTEST_INSTALL_FAILURE_SIGNAL_HANDLER=1 //path/to/your:test

The "--define absl=1" part enables stacktraces on assertion/expectation
failures.

The "--test_env=GTEST_INSTALL_FAILURE_SIGNAL_HANDLER=1" part enables
the signal handler that logs a stacktrace in the event of a crash
(this also requires the "--define absl=1" part). This is not the
default since it may interfere with existing tests.

and x64_windows_msvc