[BUG] Fail to build with `-Werror` on macOS.

[divVerent]

Describe the bug
Compile warnings on macOS. Breaks build of BoringSSL because that one uses -Werror in its own cxxopts.

System
Which OS, compiler, and compiler version are you using:

• OS: macOS 26.5.2
• Compiler and version: Apple clang version 21.0.0 (clang-2100.1.1.101); Target: arm64-apple-darwin25.5.0; Thread model: posix

To reproduce
Steps to reproduce the behavior:

1. sync to commit 8b66b54f7e1bf6b25390dca1dea3f18a40e607f9
2. bazel build --cxxopt=-Werror :all (or even just bazel build :all)
3. See error (or multiple screen pages of warning spam)

Actual behavior

INFO: Analyzed 3 targets (0 packages loaded, 627 targets configured).
ERROR: /private/tmp/benchmark/BUILD.bazel:41:11: Compiling src/benchmark_runner.cc failed: (Exit 1): cc_wrapper.sh failed: error executing CppCompile command (from target //:benchmark) external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object ... (remaining 43 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from src/benchmark_runner.cc:15:
In file included from src/benchmark_runner.h:23:
In file included from src/perf_counters.h:30:
src/mutex.h:79:40: error: mutex 'mut_' is still held at the end of function [-Werror,-Wthread-safety-analysis]
   79 |   void lock() ACQUIRE() { mut_.lock(); }
      |                                        ^
src/mutex.h:79:32: note: mutex acquired here
   79 |   void lock() ACQUIRE() { mut_.lock(); }
      |                                ^
src/mutex.h:80:34: error: releasing mutex 'mut_' that was not held [-Werror,-Wthread-safety-analysis]
   80 |   void unlock() RELEASE() { mut_.unlock(); }
      |                                  ^
2 errors generated.
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.202s, Critical Path: 1.00s
INFO: 14 processes: 1 action cache hit, 9 internal, 5 darwin-sandbox.
ERROR: Build did NOT complete successfully

Expected behavior
A working build.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Can workaround by also passing --cxxopt=-DHAVE_THREAD_SAFETY_ATTRIBUTES=1. Suggest adding this to your BUILD.bazel. Does Bazel even work with any compilers that don't support thread safety attributes?

Our workaround: https://boringssl-review.googlesource.com/c/boringssl/+/99447

[LebedevRI]

Are you enabling -Wthread-safety-analysis for the library build?
That isn't something that can just be turned on, as you've discovered.
I'm not sure what the state of the art is with those annotations,
but certainly, one needs to at least also pass that define.

[divVerent]

I was not using any flags whatsoever, merely bazel build :all.

The problem might be specific to macOS.

[divVerent]

In bazel aquery :all, I do see -Wthread-safety. I didn't add it though.

The config is darwin_arm64-fastbuild, and I got bazelisk from Homebrew.

Seems Bazel indeed wants to enable it by default if available: https://github.com/bazelbuild/rules_cc/blob/edc6a8d7227d76d798ac4041efc8fdacee9d5fd7/cc/private/toolchain/unix_cc_configure.bzl#L663

On Linux it passes -Wthread-safety too, but it doesn't warn for Google Benchmark. Something's different about Apple's Clang.

[LebedevRI]

(I'm guessing the fact that libc++ is the default on Apple.)

[divVerent]

Also, I realized that GCC (at least in Debian Stable's version) doesn't support these annotations, so it's not as simple as just always enabling them.

Maybe we need automatic feature detection e.g. via __has_attribute instead? As IIRC in Bazel we can't do any "conftest" builds.

Something along the lines of:

#if !defined(HAVE_THREAD_SAFETY_ATTRIBUTES)
# if defined __has_attribute
#  if __has_attribute(capability)
#   define HAVE_THREAD_SAFETY_ATTRIBUTES 1
#  endif
# endif
#endif
// ...
#if HAVE_THREAD_SAFETY_ATTRIBUTES

would allow one still be able to specify -DHAVE_THREAD_SAFETY_ATTRIBUTES=0 to override. (Not 100% sure if capability implies all the others though)