[libcxx-commits] [libcxx] [libc++][hardening] Categorize assertions related to strict weak ordering (PR #77405)

[Konstantin Varlamov via libcxx-commits]

================
@@ -283,9 +283,20 @@
 // - `_LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR` -- checks any operations that exchange nodes between containers to make sure
 //   the containers have compatible allocators.
 //
+// - `_LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN` -- checks that the given argument is within the domain of valid arguments
+//   for the function. Violating this typically produces an incorrect result (e.g. the clamp algorithm returns the
+//   original value without clamping it due to incorrect functors) or puts an object into an invalid state (e.g.
+//   a string view where only a subset of elements is possible to access). This doesn't cause an immediate issue within
+//   the library but is always a logic bug and is likely to cause problems within user code.
+//   This is somewhat of a catch-all (or fallback) category -- it covers errors triggered by user input that don't have
+//   a more specific category defined (which is always preferable when available).
+//
 // - `_LIBCPP_ASSERT_PEDANTIC` -- checks prerequisites which are imposed by the Standard, but violating which happens to
 //   be benign in our implementation.
 //
+// - `_LIBCPP_ASSERT_INTRUSIVE` -- for assertions that perform intrusive and typically very expensive validations of
----------------
var-const wrote:

I think having a separate category for expensive assertions makes sense -- I'm a little hesitant to add a separate category for strict weak ordering specifically, thinking it might be too narrow (but open to be persuaded otherwise). Some alternative names:
- `expensive` -- I think it's a reasonable name but "intrusive" seemed a little more specific to me (I expect these kinds of checks to be intrusive, although if that's not true, that would be an argument against "intrusive");
- `debug` -- while I expect these to only be enabled in the debug mode, I think we should still aim to maintain some orthogonality between categories and modes;
- `extensive` -- overlaps with the category name in a confusing manner;
- `paranoid` -- there's definitely precedent for this term in the security field but perhaps I'd prefer a more neutral-sounding name.

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