TTobias Hieta[libc++] Fix GNU/Hurd build
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Fix GNU/Hurd build GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete. Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D158584 (cherry picked from commit 1cfcc36812ff7857567f7c729c22ae0e2be0fb3a) | 2 年前 | |
[libc++] Remove the legacy debug mode. See https://discourse.llvm.org/t/rfc-removing-the-legacy-debug-mode-from-libc/71026 Reviewed By: #libc, Mordante, ldionne Differential Revision: https://reviews.llvm.org/D153672 | 2 年前 | |
[libc++] Make sure we use the libdispatch backend on Apple platforms The Apple.cmake cache wasn't set up properly, so we wouldn't enable the libdispatch backend by default on Apple platforms. This patch fixes the issue and adds a test. We also need to make various drive-by fixes: - Drop the usage of std::vector in libdispatch.h to avoid changing the transitive includes only on Apple platforms. - Fix includes - Use __construct at since construct_at is unavailable in C++17 - Get rid of the (unused) __get_memory_resource function since that adds a back-deployment requirement and we don't use it right now. - Fix bugs in the chunking logic around boundary conditions. Differential Revision: https://reviews.llvm.org/D155649 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 3 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 3 年前 | |
[libc++][print] Adds FILE functions. Drive-by fix to make sure the __retarget_buffer works correctly whan using a hint of 1. This was discovered in one of the new tests. Drive-by fixes __retarget_buffer when initialized with size 1. Implements parts of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D150044 | 2 年前 | |
[libc++] Refactor __less This simplifies the usage of __less by making the class not depend on the types compared, but instead the operator(). We can't remove the template completely because we explicitly instantiate std::__sort with __less<T>. Reviewed By: ldionne, #libc Spies: arichardson, EricWF, libcxx-commits, mgrang Differential Revision: https://reviews.llvm.org/D145285 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Make sure we use __ulock on Apple platforms We forgot to include the header, which means that _LIBCPP_USE_ULOCK was always undefined and we'd always use the fallback. Note that this doesn't seem to fix https://github.com/llvm/llvm-project/issues/63737. Differential Revision: https://reviews.llvm.org/D154718 | 2 年前 | |
[libc++] Remove conditional include | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Fix GNU/Hurd build GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete. Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D158584 (cherry picked from commit 1cfcc36812ff7857567f7c729c22ae0e2be0fb3a) | 2 年前 | |
Ensure newlines at the end of files (NFC) | 4 年前 | |
[libc++] Granularize system_error. Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D147853 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS Other macros that disable parts of the library are named _LIBCPP_HAS_NO_WHATEVER. Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits, smeenai Differential Revision: https://reviews.llvm.org/D143163 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS Other macros that disable parts of the library are named _LIBCPP_HAS_NO_WHATEVER. Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits, smeenai Differential Revision: https://reviews.llvm.org/D143163 | 3 年前 | |
[libc++] Roll up fstream support into filesystem support LIBCXX_ENABLE_FILESYSTEM should represent whether the platform has support for a filesystem, not just whether we support <filesystem>. This patch slightly generalizes the setting to also encompass whether we provide <fstream>, since that only makes sense when a filesystem is supported. Differential Revision: https://reviews.llvm.org/D152168 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
Ensure newlines at the end of files (NFC) | 4 年前 | |
[libc++] Add a lightweight overridable assertion handler This patch adds a lightweight assertion handler mechanism that can be overriden at link-time in a fashion similar to operator new. This is a third take on https://llvm.org/D121123 (which allowed customizing the assertion handler at compile-time), and https://llvm.org/D119969 (which allowed customizing the assertion handler at runtime only). This approach is, I think, the best of all three explored approaches. Indeed, replacing the assertion handler in user code is ergonomic, yet we retain the ability to provide a custom assertion handler when deploying to older platforms that don't have a default handler in the dylib. As-is, this patch provides a pretty good amount of backwards compatibility with the previous debug mode: - Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions in their code will still get basic assertions out of the box, but those assertions will be using the new assertion handler support. - Code that was previously compiled with references to __libcpp_debug_function and friends will work out-of-the-box, no changes required. This is because we provide the same symbols in the dylib as we used to. - Code that used to set a custom __libcpp_debug_function will stop compiling, because we don't provide that declaration anymore. Users will have to migrate to the new way of setting a custom assertion handler, which is extremely easy. I suspect that pool of users is very limited, so breaking them at compile-time is probably acceptable. The main downside of this approach is that code being compiled with assertions enabled but deploying to an older platform where the assertion handler didn't exist yet will fail to compile. However users can easily fix the problem by providing a custom assertion handler and defining the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to let the library know about the custom handler. In a way, this is actually a feature because it avoids a load-time error that one would otherwise get when trying to run the code on the older target. Differential Revision: https://reviews.llvm.org/D121478 | 4 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Use _LIBCPP_VERBOSE_ABORT in a few remaining __throw_FOO functions This provides better error messages when the program terminates due to an exception being thrown in -fno-exceptions mode. Those seem to have been missed in https://reviews.llvm.org/D141222. Differential Revision: https://reviews.llvm.org/D154995 | 2 年前 | |
[libc++] Remove symbols for a std::allocator_arg & friends from the dylib This patch removes the symbols defined in the library for std::allocator_arg, std::defer_lock, std::try_to_lock, std::adopt_lock, and std::piecewise_construct. Those were defined in the library because we provided them in C++03 as an extension, and in C++03 it was impossible to define them as constexpr variables, like in the spec. This is technically an ABI break since we are removing symbols from the library. However, in practice, only programs compiled in C++03 mode who take the address of those objects (or pass them as a reference) will have an undefined ref to those symbols. In practice, this is expected to be rare. First, those are C++11 features that we happen to provide in C++03, and only the C++03 definition can potentially lead to code referencing the dylib definition. So any code that is using these objects but compiling in C++11 mode (as they should) is not at risk. Second, all uses of these types in the library is done by passing those types by value to a function that can get inlined. Since they are empty types, the compiler won't generate an undefined reference if passed by value, since there's nothing to pass anyway. Long story short, the risk for code actually containing an undefined reference to one of these types is rather small (but non-zero). I also couldn't find any app on the App Store that referenced these symbols, which supports my impression that this won't be an issue in practice. Differential Revision: https://reviews.llvm.org/D145587 | 3 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 3 年前 | |
[libc++] Add the C++17 <memory_resource> header (mono-patch) This patch is the rebase and squash of three earlier patches. It supersedes all three of them. - D47111: experimental monotonic_buffer_resource. - D47358: experimental pool resources. - D47360: Copy std::experimental::pmr to std::pmr. The significant difference between this patch and the-sum-of-those-three is that this patch does not add std::experimental::pmr::monotonic_buffer_resource and so on. This patch simply adds the C++17 standard facilities, and leaves the std::experimental namespace entirely alone. Differential Revision: https://reviews.llvm.org/D89057 | 3 年前 | |
[libc++] Move __thread_id out of <__threading_support> This makes <__threading_support> closer to handling only the bridge between the system's implementation of threading and the rest of libc++. Differential Revision: https://reviews.llvm.org/D154464 | 2 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Get rid of _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS Whether we include operator new and delete into libc++ has always been a build time setting, and piggy-backing on a macro like _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS is inconsistent with how we handle similar cases for e.g. LIBCXX_ENABLE_RANDOM_DEVICE. Instead, simply avoid including new.cpp in the sources of the library when we do not wish to include these operators in the build. This also makes us much closer to being able to share the definitions between libc++ and libc++abi, since we could technically build those definitions into a standalone static library and decide whether we link it into libc++abi.dylib or libc++.dylib. Differential Revision: https://reviews.llvm.org/D153272 | 3 年前 | |
[libc++][NFC] clang-format new_handler.cpp | 3 年前 | |
[libc++] Move non operator new definitions outside of new.cpp This makes it such that new.cpp contains only the definitions of operator new and operator delete, like its libc++abi counterpart. Differential Revision: https://reviews.llvm.org/D153136 | 3 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++][print] Adds FILE functions. Drive-by fix to make sure the __retarget_buffer works correctly whan using a hint of 1. This was discovered in one of the new tests. Drive-by fixes __retarget_buffer when initialized with size 1. Implements parts of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D150044 | 2 年前 | |
[libc++] Remove Solaris related code This was contributed ~10 years ago, but we don't officially support it and I am not aware of any bot testing it, so this has likely rotten to the point where it is unusable. Differential Revision: https://reviews.llvm.org/D138680 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++][NFC] clang-format <shared_mutex> I am about to touch several lines in that file for a patch anyway, so I might as well clang-format it upfront to avoid mixing styles after my patch. | 2 年前 | |
[libcxx] Fix using std::wcout/wcin on Windows with streams configured in wide mode On Windows, the underlying file descriptors for stdout/stdin/stderr can be reconfigured to wide mode. In the default (narrow) mode, the charset usually isn't utf8 (as libcxx assumes), but normally a locale specific codepage (where each codepage only can represent a small subset of unicode characters). By configuring the stdout file descriptor to wide mode, the user can output wchar_t based strings without convesion to the narrow charset. Within libcxx, don't try to use codecvt to convert this to a narrow character encoding, but output these strings as such with fputwc. In wide mode, such strings could be output directly with fwrite too, but if the file descriptor hasn't been configured in wide mode, that breaks the output (which currently works reasonably). By always outputting one character at a time with fputwc, it works regardless of mode of the stdout file descriptor. For the narrow output stream, std::cout, outputting (via fwrite) does fail when the file descriptor is set to wide mode. This matches how it behaves with both MS STL and GNU libstdc++ too, so this is probably acceptable. This fixes https://github.com/llvm/llvm-project/issues/46646, and the downstream bugs https://github.com/mstorsjo/llvm-mingw/issues/145 and https://github.com/mstorsjo/llvm-mingw/issues/222. Differential Revision: https://reviews.llvm.org/D146398 | 3 年前 | |
[libc++] Granularize system_error. Reviewed By: #libc, philnik Differential Revision: https://reviews.llvm.org/D147853 | 3 年前 | |
[libc++][hardening] Categorize more assertions. Differential Revision: https://reviews.llvm.org/D155873 | 2 年前 | |
[libc++][hardening][NFC] Introduce _LIBCPP_ASSERT_UNCATEGORIZED. Replace most uses of _LIBCPP_ASSERT with _LIBCPP_ASSERT_UNCATEGORIZED. This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on _LIBCPP_ASSERT (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior). Differential Revision: https://reviews.llvm.org/D153816 | 3 年前 | |
[libc++] Use _LIBCPP_VERBOSE_ABORT in a few remaining __throw_FOO functions This provides better error messages when the program terminates due to an exception being thrown in -fno-exceptions mode. Those seem to have been missed in https://reviews.llvm.org/D141222. Differential Revision: https://reviews.llvm.org/D154995 | 2 年前 | |
[libc++][NFC] Granularise <thread> header - This was to make implementing jthread easier and requested in https://reviews.llvm.org/D151559 Differential Revision: https://reviews.llvm.org/D151792 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI These macros are always defined identically, so we can simplify the code a bit by merging them. Reviewed By: ldionne, #libc Spies: libcxx-commits, krytarowski, smeenai Differential Revision: https://reviews.llvm.org/D152652 | 3 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++] Replace #include "" with <> in libcxx/src/. NFCI. Our best guess is that the two syntaxes should have exactly equivalent effects, so, let's be consistent with what we do in libcxx/include/. I've left #include "include/x.h" and #include "../y.h" alone because I'm less sure that they're interchangeable, and they aren't inconsistent with libcxx/include/ because libcxx/include/ never does that kind of thing. Also, use the _LIBCPP_PUSH_MACROS/POP_MACROS dance for <__undef_macros>, even though it's technically unnecessary in a standalone .cpp file, just so we have consistently one way to do it. Differential Revision: https://reviews.llvm.org/D119561 | 4 年前 | |
[libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abort With the goal of reusing that handler to do other things besides handling assertions (such as terminating when an exception is thrown under -fno-exceptions), the name __libcpp_assertion_handler doesn't really make sense anymore. Furthermore, I didn't want to use the name __libcpp_abort_handler, since that would give the impression that the handler is called whenever std::abort() is called, which is not the case at all. Differential Revision: https://reviews.llvm.org/D130562 | 3 年前 |