[libcxx-commits] [libcxx] [libc++][hardening] Rework how the assertion handler can be overridden. (PR #77883)

[Konstantin Varlamov via libcxx-commits]

================
@@ -69,6 +69,13 @@ if (NOT "${LIBCXX_HARDENING_MODE}" IN_LIST LIBCXX_SUPPORTED_HARDENING_MODES)
   message(FATAL_ERROR
     "Unsupported hardening mode: '${LIBCXX_HARDENING_MODE}'. Supported values are ${LIBCXX_SUPPORTED_HARDENING_MODES}.")
 endif()
+set(LIBCXX_ASSERTION_HANDLER_FILE
+  "${CMAKE_CURRENT_SOURCE_DIR}/vendor/llvm/default_assertion_handler.in"
+  CACHE STRING
+  "Specify the path to a header that contains a custom implementation of the
+   assertion handler that gets invoked when a hardening assertion fails. If
+   provided, the contents of this header will get injected into the library code
+   and override the default assertion handler.")
----------------
var-const wrote:

Injecting the contents of the header should give us a little more control over the custom handler. In particular, it is currently up to the vendor whether they want to allow users to override the macro. To support overriding, a custom implementation might first check that the macro isn't already defined, e.g. on the command line:
```cpp
// In a vendor-provided `./custom_assertion_handler.h`
#ifndef _LIBCPP_ASSERTION_HANDLER
#define _LIBCPP_ASSERTION_HANDLER(...) platform::assert(__VA_ARGS__)
#endif
```
That way, a user can compile with `-D_LIBCPP_ASSERTION_HANDLER(...)=my_project::special_assert(__VA_ARGS__)` and it will be honored. Or the vendor could do the opposite and explicitly forbid overriding:
```cpp
#ifdef _LIBCPP_ASSERTION_HANDLER
#error "You should not attempt to override the platform-provided assertion handler"
#endif
```

If in a future release we wanted to make sure that the handler can always be overridden by users, we could change our header to do something like:
```cpp
#ifndef _LIBCPP_ASSERTION_HANDLER
@_LIBCPP_ASSERTION_HANDLER_OVERRIDE@
#endif
```

We don't necessarily want to do that, but I think leaving us some degree of flexibility in this regard is useful.

Also, this allows us to provide some internal includes for the custom header in a supported manner. E.g. we can make `<__config>` available without having the vendor include that internal header explicitly (which we generally don't support), and if in the future we decided to granularize `<__config>`, we could update the includes without the vendor having to update their code.

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