summaryrefslogtreecommitdiff
path: root/libcxx/src/hash.cpp
AgeCommit message (Collapse)Author
2025-06-11[libc++] Remove static_assert from hash.cpp that fires unconditionallNikolas Klauser
2025-06-11[libc++] Simplify the implementation of __next_prime a bit (#143512)Nikolas Klauser
2025-05-28Revert "[libc++] Introduce ABI sensitive areas to avoid requiring ↵James Y Knight
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756) This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521. Unfortunately, this use of hidden visibility attributes causes user-defined specializations of standard-library types to also be marked hidden by default, which is incorrect. See discussion thread on #131156. ...and also reverts the follow-up commits: Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)" This reverts commit 3e4c9dc299c35155934688184319d391b298fff7. Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)" This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5. Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)" This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
2025-05-18[libc++] Introduce ABI sensitive areas to avoid requiring ↵Nikolas Klauser
_LIBCPP_HIDE_FROM_ABI everywhere (#131156) This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`, which allow us to have implicit annotations for most functions, and just where it's not "hide_from_abi everything" we add explicit annotations. This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most functions in libc++.
2025-02-21[libc++] Qualify calls to nullary functions like __throw_foo (#122465)Louis Dionne
This is technically not necessary in most cases to prevent issues with ADL, but let's be consistent. This allows us to remove the libcpp-qualify-declval clang-tidy check, which is now enforced by the robust-against-adl clang-tidy check.
2023-12-18[libc++] Format the code base (#74334)Louis Dionne
This patch runs clang-format on all of libcxx/include and libcxx/src, in accordance with the RFC discussed at [1]. Follow-up patches will format the benchmarks, the test suite and remaining parts of the code. I'm splitting this one into its own patch so the diff is a bit easier to review. This patch was generated with: find libcxx/include libcxx/src -type f \ | grep -v 'module.modulemap.in' \ | grep -v 'CMakeLists.txt' \ | grep -v 'README.txt' \ | grep -v 'libcxx.imp' \ | grep -v '__config_site.in' \ | xargs clang-format -i A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh to help resolve merge and rebase issues across these formatting changes. [1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-04[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)Louis Dionne
In preparation for running clang-format on the whole code base, we are also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in favor of the newer _LIBCPP_HIDE_FROM_ABI. We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid creating needless breakage in case some older patches are checked-in with mentions of the old macro. After we branch for LLVM 18, we can do another pass to clean up remaining uses of the macro that might have gotten introduced by mistake (if any) and remove the macro itself at the same time. This is just a minor convenience to smooth out the transition as much as possible. See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all for the clang-format proposal.
2022-02-15[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.Arthur O'Dwyer
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
2022-02-15[libc++] Guard warning pragmasNikolas Klauser
This makes the GCC output even cleaner! Reviewed By: ldionne, #libc Spies: mstorsjo, Quuxplusone, Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D119295
2021-11-17[runtimes][NFC] Remove filenames at the top of the license noticeLouis Dionne
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
2019-02-12[libc++] Avoid UB in the no-exceptions mode in a few placesLouis Dionne
Summary: A few places in the library seem to behave unexpectedly when the library is compiled or used with exceptions disabled. For example, not throwing an exception when a pointer is NULL can lead us to dereference the pointer later on, which is UB. This patch fixes such occurences. It's hard to tell whether there are other places where the no-exceptions mode misbehaves like this, because the replacement for throwing an exception does not always seem to be abort()ing, but at least this patch will improve the situation somewhat. See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D57761 llvm-svn: 353850
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
2014-05-15Fix typosAlp Toker
llvm-svn: 208869
2013-04-27Only use Clang pragma when compiling with clang.Joerg Sonnenberger
llvm-svn: 180678
2013-03-28Fix a few warnings/errors for compiling with -fno-exceptions.Howard Hinnant
llvm-svn: 178267
2012-12-27Saleem Abdulrasool: avoid hardcoding buffer lengths.Howard Hinnant
llvm-svn: 171169
2012-12-27Saleem Abdulrasool: Silence warning and reduce unnecessary code in hash.cpp.Howard Hinnant
llvm-svn: 171167
2011-12-01Quash a whole bunch of warningsHoward Hinnant
llvm-svn: 145624
2010-11-16license changeHoward Hinnant
llvm-svn: 119395
2010-10-29Secure __next_prime from overflowingHoward Hinnant
llvm-svn: 117650
2010-09-13Experimenting with a new forward fomulation (kudos Daniel Kruegler), updated ↵Howard Hinnant
insert iterators to work better with pproxies, and doubled the speed of __next_prime. llvm-svn: 113731
2010-08-22Fixing whitespace problemsHoward Hinnant
llvm-svn: 111751
2010-05-11Wiped out some non-ascii characters that snuck into the copyright.Howard Hinnant
llvm-svn: 103516
2010-05-11libcxx initial importHoward Hinnant
llvm-svn: 103490