-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[libc++] Add a escape hatch for making __libcpp_verbose_abort non-noexcept again #113310
[libc++] Add a escape hatch for making __libcpp_verbose_abort non-noexcept again #113310
Conversation
@llvm/pr-subscribers-libcxx Author: Louis Dionne (ldionne) ChangesThis allows a slightly smoother transition for people after #109151, as requested on that PR. Full diff: https://github.com/llvm/llvm-project/pull/113310.diff 3 Files Affected:
diff --git a/libcxx/docs/ReleaseNotes/20.rst b/libcxx/docs/ReleaseNotes/20.rst
index 44912d2ddafac6..39546493ae8d6f 100644
--- a/libcxx/docs/ReleaseNotes/20.rst
+++ b/libcxx/docs/ReleaseNotes/20.rst
@@ -83,7 +83,9 @@ Deprecations and Removals
ambiguity in name lookup. Code that expects such ambiguity will possibly not compile in LLVM 20.
- The function ``__libcpp_verbose_abort()`` is now ``noexcept``, to match ``std::terminate()``. (The combination of
- ``noexcept`` and ``[[noreturn]]`` has special significance for function effects analysis.)
+ ``noexcept`` and ``[[noreturn]]`` has special significance for function effects analysis.) For backwards compatibility,
+ the ``_LIBCPP_VERBOSE_ABORT_NOT_NOEXCEPT`` macro can be defined to make the function non-``noexcept``. That macro
+ will be removed in LLVM 21.
Upcoming Deprecations and Removals
----------------------------------
@@ -106,6 +108,9 @@ LLVM 21
If you are using C++03 in your project, you should consider moving to a newer version of the Standard to get the most
out of libc++.
+- The ``_LIBCPP_VERBOSE_ABORT_NOT_NOEXCEPT`` macro will be removed in LLVM 21, making ``std::__libcpp_verbose_abort``
+ unconditionally ``noexcept``.
+
ABI Affecting Changes
---------------------
diff --git a/libcxx/include/__verbose_abort b/libcxx/include/__verbose_abort
index 73295cae426102..c975ea7f91c919 100644
--- a/libcxx/include/__verbose_abort
+++ b/libcxx/include/__verbose_abort
@@ -18,10 +18,16 @@
_LIBCPP_BEGIN_NAMESPACE_STD
+#if defined(_LIBCPP_VERBOSE_ABORT_NOT_NOEXCEPT)
+# define _LIBCPP_VERBOSE_ABORT_NOEXCEPT
+#else
+# define _LIBCPP_VERBOSE_ABORT_NOEXCEPT _NOEXCEPT
+#endif
+
// This function should never be called directly from the code -- it should only be called through
// the _LIBCPP_VERBOSE_ABORT macro.
[[__noreturn__]] _LIBCPP_AVAILABILITY_VERBOSE_ABORT _LIBCPP_OVERRIDABLE_FUNC_VIS
-_LIBCPP_ATTRIBUTE_FORMAT(__printf__, 1, 2) void __libcpp_verbose_abort(const char* __format, ...) _NOEXCEPT;
+_LIBCPP_ATTRIBUTE_FORMAT(__printf__, 1, 2) void __libcpp_verbose_abort(const char* __format, ...) _LIBCPP_VERBOSE_ABORT_NOEXCEPT;
// _LIBCPP_VERBOSE_ABORT(format, args...)
//
diff --git a/libcxx/src/verbose_abort.cpp b/libcxx/src/verbose_abort.cpp
index 0019063405a810..6704709d247ca1 100644
--- a/libcxx/src/verbose_abort.cpp
+++ b/libcxx/src/verbose_abort.cpp
@@ -28,7 +28,7 @@ extern "C" void android_set_abort_message(const char* msg);
_LIBCPP_BEGIN_NAMESPACE_STD
-_LIBCPP_WEAK void __libcpp_verbose_abort(char const* format, ...) noexcept {
+_LIBCPP_WEAK void __libcpp_verbose_abort(char const* format, ...) _LIBCPP_VERBOSE_ABORT_NOEXCEPT {
// Write message to stderr. We do this before formatting into a
// buffer so that we still get some information out if that fails.
{
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
@Caslyn This is the escape hatch you requested. |
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/52/builds/3154 Here is the relevant piece of the build log for the reference
|
Thanks @ldionne! |
…xcept again (llvm#113310) This allows a slightly smoother transition for people after llvm#109151, as requested on that PR.
This allows a slightly smoother transition for people after #109151, as requested on that PR.