[libcxx-commits] [libcxx] [libc++] Handle Clang function effect analysis in hardening assertions (PR #177447)

Louis Dionne via libcxx-commits libcxx-commits at lists.llvm.org
Fri Jan 23 07:25:52 PST 2026


================
@@ -17,11 +17,17 @@
 #  pragma GCC system_header
 #endif
 
+// Note that we disable -Wfunction-effects inside _LIBCPP_ASSERT when the assertion fails since
+// function effect attributes don't provide any guarantees once a function is determined to be
+// out of contract.
 #define _LIBCPP_ASSERT(expression, message)                                                                            \
   (__builtin_expect(static_cast<bool>(expression), 1)                                                                  \
        ? (void)0                                                                                                       \
-       : _LIBCPP_ASSERTION_HANDLER(__FILE__ ":" _LIBCPP_TOSTRING(                                                      \
-             __LINE__) ": libc++ Hardening assertion " _LIBCPP_TOSTRING(expression) " failed: " message "\n"))
+       : _LIBCPP_DIAGNOSTIC_PUSH                                    /*                                              */ \
----------------
ldionne wrote:

Your Godbolt doesn't exhibit the problem because you're using `__builtin_verbose_trap`. You have to enable the observe mode for this issue to be visible: https://godbolt.org/z/eP1jbnvsc

> While usually acceptable, pushing and popping diagnostics is a relatively expensive operation

What's the fundamental reason for it being expensive? FWIW, while we should be cognizant of these costs, it's also a dangerous slippery slope to start taking into account the cost of something like this for determining the value of this patch.

That being said, I don't think this discussion is relevant anymore: it seems like the push/pop macro approach doesn't work after all, because while it silences the diagnostic around the assertion, `span::operator[]` still ends up being considered a potentially-blocking function. Hence, you still get a warning when you call `operator[]` from a non-blocking function: https://godbolt.org/z/o9Ee4ccGj.

https://github.com/llvm/llvm-project/pull/177447


More information about the libcxx-commits mailing list