[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