en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#3a55353f [libc++] Rename __libcpp_assertion_handler to __libcpp_verbose_abortWith the goal of reusing that handler to do other things besideshandling assertions (such as terminating when an exception is thrownunder -fno-exceptions), the name `__libcpp_assertion_handler` doesn'treally 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 calledwhenever `std::abort()` is called, which is not the case at all.Differential Revision: https://reviews.llvm.org/D130562(cherry picked from commit 507125af3d0b953cb56bce2e5b8000249fe1ef53) List of files: /llvm-project-15.0.7/libcxx/include/__assert Mon, 25 Jul 2022 17:43:47 +0000 Louis Dionne <ldionne.2@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#7de5aca8 [libc++] Generalize the customizeable assertion handlerInstead of taking a fixed set of arguments, use variadics so thatwe can pass arbitrary arguments to the handler. This is the firststep towards using the handler to handle other non-assertion-relatedfailures, like std::unreachable and an exception being thrown in-fno-exceptions mode, which would improve user experience by includingadditional information in crashes (right now, we call abort() withoutadditional information).Differential Revision: https://reviews.llvm.org/D130507 List of files: /llvm-project-15.0.7/libcxx/include/__assert Mon, 25 Jul 2022 17:19:51 +0000 Louis Dionne <ldionne.2@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#f3966eaf [libc++] Make the Debug mode a configuration-time only optionThe debug mode has been broken pretty much ever since it was shippedbecause it was possible to enable the debug mode in user code withoutactually enabling it in the dylib, leading to ODR violations thatcaused various kinds of failures.This commit makes the debug mode a knob that is configured whenbuilding the library and which can't be changed afterwards. This isless flexible for users, however it will actually work as intendedand it will allow us, in the future, to add various kinds of checksthat do not assume the same ABI as the normal library. Furthermore,this will make the debug mode more robust, which means that vendorsmight be more tempted to support it properly, which hasn't been thecase with the current debug mode.This patch shouldn't break any user code, except folks who are buildingagainst a library that doesn't have the debug mode enabled and who tryto enable the debug mode in their code. Such users will get a compile-timeerror explaining that this configuration isn't supported anymore.In the future, we should further increase the granularity of the debugmode checks so that we can cherry-pick which checks to enable, like wedo for unspecified behavior randomization.Differential Revision: https://reviews.llvm.org/D122941 List of files: /llvm-project-15.0.7/libcxx/include/__assert Fri, 01 Apr 2022 20:38:30 +0000 Louis Dionne <ldionne.2@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#0a77e633 [libcxx] Add flag to disable __builtin_assume in _LIBCPP_ASSERTIntroduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERTnot call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.Calling __builtin_assume was introduced in D122397.__builtin_assume is generally supposed to improve optimizations, but cancause regressions when LLVM has trouble handling the calls to`llvm.assume()` (see comments in D122397).Reviewed By: philnikDifferential Revision: https://reviews.llvm.org/D123175 List of files: /llvm-project-15.0.7/libcxx/include/__assert Wed, 06 Apr 2022 02:16:39 +0000 Arthur Eubanks <aeubanks@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#f0799465 [libc++] Use __builtin_expect and __builtin_assume in _LIBCPP_ASSERTSince we expect the condition to be true most of the time, we mightas well tell the compiler. And when assertions are disabled, wemight as well tell the compiler that it's allowed to assume thatthe condition holds.Differential Revision: https://reviews.llvm.org/D122397 List of files: /llvm-project-15.0.7/libcxx/include/__assert Thu, 24 Mar 2022 13:27:03 +0000 Louis Dionne <ldionne.2@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#b0fd9497 [libc++] Add a lightweight overridable assertion handlerThis patch adds a lightweight assertion handler mechanism that can beoverriden at link-time in a fashion similar to `operator new`.This is a third take on https://llvm.org/D121123 (which allowed customizingthe 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 whendeploying to older platforms that don't have a default handler inthe dylib.As-is, this patch provides a pretty good amount of backwards compatibilitywith 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 withassertions enabled but deploying to an older platform where the assertionhandler didn't exist yet will fail to compile. However users can easilyfix the problem by providing a custom assertion handler and definingthe _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro tolet the library know about the custom handler. In a way, this isactually a feature because it avoids a load-time error that one wouldotherwise get when trying to run the code on the older target.Differential Revision: https://reviews.llvm.org/D121478 List of files: /llvm-project-15.0.7/libcxx/include/__assert Thu, 03 Mar 2022 22:37:03 +0000 Louis Dionne <ldionne.2@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#95c0f2d1 [libc++] Remove workarounds for re-defining _LIBCPP_ASSERT in the test suiteAs a fly-by fix, enable the complexity-changing assertions in __debug_lessonly when the full debug mode is enabled, since debugging level 0 is usuallyunderstood to only contain basic assertions that do not change the complexityof algorithms.Differential Revision: https://reviews.llvm.org/D121129 List of files: /llvm-project-15.0.7/libcxx/include/__assert Mon, 07 Mar 2022 16:31:45 +0000 Louis Dionne <ldionne.2@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/libcxx/include/__assert#f87aa19b [libc++] Move everything related solely to _LIBCPP_ASSERT to its own fileThis is the first step towards disentangling the debug mode and assertionsin libc++. This patch doesn't make any functional change: it simply moves_LIBCPP_ASSERT-related stuff to its own file so as to make it clear thatlibc++ assertions and the debug mode are different things. Future patcheswill make it possible to enable assertions without enabling the debugmode.Differential Revision: https://reviews.llvm.org/D119769 List of files: /llvm-project-15.0.7/libcxx/include/__assert Mon, 14 Feb 2022 18:41:09 +0000 Louis Dionne <ldionne.2@gmail.com>