Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
902e62cf |
| 23-Dec-2024 |
Petr Hosek <phosek@google.com> |
[libcxx] Fix the #endif comments (#120949)
The order of comments is swapped.
|
#
d039ac39 |
| 23-Dec-2024 |
Petr Hosek <phosek@google.com> |
[libcxx] Remove the second inclusion of the system header (#120946)
This was introduced in #119025 and not only seems unnecessary, it broke
the build with older versions of glibc.
|
#
b9a2658a |
| 21-Dec-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)
This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-
[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)
This patch implements the forwarding to frozen C++03 headers as discussed in https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the RFC, we initially proposed selecting the right headers from the Clang driver, however consensus seemed to steer towards handling this in the library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public header look like this:
``` // inside <vector> #ifdef _LIBCPP_CXX03_LANG # include <__cxx03/vector> #else // normal <vector> content #endif ```
In most cases, public headers are simple umbrella headers so there isn't much code in the #else branch. In other cases, the #else branch contains the actual implementation of the header.
show more ...
|
#
ce4ac994 |
| 17-Dec-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove explicit mentions of __need_FOO macros (#119025)
This change has a long history. It was first attempted naively in
https://reviews.llvm.org/D131425, which didn't work because we bro
[libc++] Remove explicit mentions of __need_FOO macros (#119025)
This change has a long history. It was first attempted naively in
https://reviews.llvm.org/D131425, which didn't work because we broke the
ability for code to include e.g. <stdio.h> multiple times and get
different definitions based on the pre-defined macros.
However, in #86843 we managed to simplify <stddef.h> by including the
underlying system header outside of any include guards, which worked.
This patch applies the same simplification we did to <stddef.h> to the
other headers that currently mention __need_FOO macros explicitly.
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
c166a9c7 |
| 10-Dec-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Add #if 0 block to all the top-level headers (#119234)
Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a sep
[libc++] Add #if 0 block to all the top-level headers (#119234)
Including The frozen C++03 headers results in a lot of formatting changes in the main headers, so this splits these changes into a separate commit instead.
This is part of https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
17e0686a |
| 12-Sep-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454)
`__has_cpp_attribute(__nodiscard__)` is always true now, so we might as
well replace `_LIBCPP_NODISCARD`. It's one less macro that can r
[libc++][NFC] Use [[__nodiscard__]] unconditionally (#80454)
`__has_cpp_attribute(__nodiscard__)` is always true now, so we might as
well replace `_LIBCPP_NODISCARD`. It's one less macro that can result in
bad diagnostics.
show more ...
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
83bc7b57 |
| 22-Apr-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Remove _LIBCPP_DISABLE_NODISCARD_EXTENSIONS and refactor the tests (#87094)
This also adds a few tests that were missing.
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
9783f28c |
| 18-Dec-2023 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Format the code base (#74334)
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 benchmar
[libc++] Format the code base (#74334)
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
show more ...
|
#
4c198542 |
| 04-Dec-2023 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)
In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLIN
[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)
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.
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6 |
|
#
3b6bc875 |
| 24-Nov-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[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
[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
show more ...
|
#
633927db |
| 25-Dec-2022 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++] Add [[nodiscard]] extensions in <math.h>
There are quite a few functions marked `[[gnu::const]]` inside the compiler. This patch adds `[[nodiscard]]` to libc++-provided overloads of these f
[libc++] Add [[nodiscard]] extensions in <math.h>
There are quite a few functions marked `[[gnu::const]]` inside the compiler. This patch adds `[[nodiscard]]` to libc++-provided overloads of these functions to match the diagnostics produced.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D140855
show more ...
|
#
3f65c8fc |
| 22-Nov-2022 |
Yi Kong <yikong@google.com> |
Revert "[libc++] Remove workarounds for systems that used to require __need_XXX macros"
This reverts commit 119cef40d18c48240854edc553dca61c4e9fdf27.
The change broke multiple builders.
|
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
#
119cef40 |
| 08-Aug-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove workarounds for systems that used to require __need_XXX macros
Libc++ tried accomodating systems that need to be able to define various __need_FOO macros before including C library h
[libc++] Remove workarounds for systems that used to require __need_XXX macros
Libc++ tried accomodating systems that need to be able to define various __need_FOO macros before including C library headers, however it does not appear to be needed anymore in most cases. Indeed, glibc used to use that system to conditionally provide definitions, however almost all instances of these macros have been removed from glibc years ago.
I think the next step would be to also fix Clang's own builtin headers to stop needing these macros.
Differential Revision: https://reviews.llvm.org/D131425
show more ...
|
#
5d87f60f |
| 15-Nov-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Only include_next C library headers when they exist
Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few fu
[libc++] Only include_next C library headers when they exist
Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next.
This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users.
NOTE: This is a reapplicaton of 226409, which was reverted in 674729813 because it broke the build. The issue has now been fixed with https://reviews.llvm.org/D138062.
Differential Revision: https://reviews.llvm.org/D136683
show more ...
|
#
67472981 |
| 15-Nov-2022 |
Nico Weber <thakis@chromium.org> |
Revert "[libc++] Only include_next C library headers when they exist"
This reverts commit 226409c62879bf5ff9928cd23a4255cd7c614fe0. Breaks check-clang on mac, see comments on https://reviews.llvm.or
Revert "[libc++] Only include_next C library headers when they exist"
This reverts commit 226409c62879bf5ff9928cd23a4255cd7c614fe0. Breaks check-clang on mac, see comments on https://reviews.llvm.org/D136683
show more ...
|
#
226409c6 |
| 25-Oct-2022 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Only include_next C library headers when they exist
Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few fu
[libc++] Only include_next C library headers when they exist
Some platforms don't provide all C library headers. In practice, libc++ only requires a few C library headers to exist, and only a few functions on those headers. Missing functions that libc++ doesn't need for its own implementation are handled properly by the using_if_exists attribute, however a missing header is currently a hard error when we try to do #include_next.
This patch should make libc++ more flexible on platforms that do not provide C headers that libc++ doesn't actually require for its own implementation. The only downside is that it may move some errors from the #include_next point to later in the compilation if we actually try to use something that isn't provided, which could be somewhat confusing. However, these errors should be caught by folks trying to port libc++ over to a new platform (when running the libc++ test suite), not by end users.
Differential Revision: https://reviews.llvm.org/D136683
show more ...
|
Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
fa6b9e40 |
| 02-Feb-2022 |
Arthur O'Dwyer <arthur.j.odwyer@gmail.com> |
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D1188
[libc++] Normalize all our '#pragma GCC system_header', and regression-test.
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D118800
show more ...
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
eb8650a7 |
| 17-Nov-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[runtimes][NFC] Remove filenames at the top of the license notice
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 st
[runtimes][NFC] Remove filenames at the top of the license notice
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.
show more ...
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
#
c137a075 |
| 24-Aug-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove _LIBCPP_HAS_NO_LONG_LONG in favour of using_if_exists
_LIBCPP_HAS_NO_LONG_LONG was only defined on FreeBSD. Instead, use the using_if_exists attribute to skip over declarations that
[libc++] Remove _LIBCPP_HAS_NO_LONG_LONG in favour of using_if_exists
_LIBCPP_HAS_NO_LONG_LONG was only defined on FreeBSD. Instead, use the using_if_exists attribute to skip over declarations that are not available on the base system. Note that there's an annoying limitation that we can't conditionally define a function based on whether the base system provides a function, so for example we still need preprocessor logic to define the abs() and div() overloads.
Differential Revision: https://reviews.llvm.org/D108630
show more ...
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
4cd6ca10 |
| 20-Apr-2021 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] NFC: Normalize `#endif //` comment indentation
|
#
f3d7536b |
| 08-Apr-2021 |
jasonliu <jasonliu.development@gmail.com> |
[libc++] Fix abs and div overload issue for compilers on AIX
Summary: AIX system's stdlib.h provide different overload of abs and div depending on compiler versions.
For example, std::div(long, lon
[libc++] Fix abs and div overload issue for compilers on AIX
Summary: AIX system's stdlib.h provide different overload of abs and div depending on compiler versions.
For example, std::div(long, long) and std::abs(long) are not available from OS's stdlib.h when building with clang, but they are available when building with xlclang compiler.
Therefore, we need to provide those extra overloads in libc++'s stdlib.h when OS's stdlib.h does not.
Differential Revision: https://reviews.llvm.org/D99767
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
#
c490c5e8 |
| 15-Feb-2020 |
Eric Fiselier <eric@efcs.ca> |
Reland [libc++] Move abs and div into stdlib.h to fix header cycle.
This commit should will break libc++ without local submodule visibility, but the LLVM+modules bots are now all using this mode. Be
Reland [libc++] Move abs and div into stdlib.h to fix header cycle.
This commit should will break libc++ without local submodule visibility, but the LLVM+modules bots are now all using this mode. Before the Green Dragon LLDB bot was failing to compile with a libc++ built with this commit as LSV was disabled on macOS.
Original summary:
libc++ is careful to not fracture overload sets. When one overload is visible to a user, all of them should be. Anything less causes subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by both <cmath> and <cstdlib> we had to do awful things that make <math.h> and <stdlib.h> have header cycles and be non-modular. This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads for floating point numbers, these overloads forward to ::fabs, which are defined in math.h. Therefore ::abs needed to be in math.h too. But this required stdlib.h to include math.h and math.h to include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h (which math includes), and the floating point overloads of ::abs have been changed to call __builtin_fabs, which both Clang and GCC support.
show more ...
|
#
bd2965c9 |
| 28-Apr-2020 |
Raphael Isemann <teemperor@gmail.com> |
Revert "Recommit [libc++] Move abs and div into stdlib.h to fix header cycle."
It seems that D74892 still hasn't fixed the issue on the bot. Currently investigating the bot breakage and meanwhile (a
Revert "Recommit [libc++] Move abs and div into stdlib.h to fix header cycle."
It seems that D74892 still hasn't fixed the issue on the bot. Currently investigating the bot breakage and meanwhile (again) reverting this...
show more ...
|
#
d0846b43 |
| 15-Feb-2020 |
Eric Fiselier <eric@efcs.ca> |
Recommit [libc++] Move abs and div into stdlib.h to fix header cycle.
This relands this commit as it broke the LLDB bot the first time it landed. See also the discussion on https://reviews.llvm.org/
Recommit [libc++] Move abs and div into stdlib.h to fix header cycle.
This relands this commit as it broke the LLDB bot the first time it landed. See also the discussion on https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
Since D74892 this code should now also work on macOS.
Original description:
libc++ is careful to not fracture overload sets. When one overload is visible to a user, all of them should be. Anything less causes subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by both <cmath> and <cstdlib> we had to do awful things that make <math.h> and <stdlib.h> have header cycles and be non-modular. This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads for floating point numbers, these overloads forward to ::fabs, which are defined in math.h. Therefore ::abs needed to be in math.h too. But this required stdlib.h to include math.h and math.h to include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h (which math includes), and the floating point overloads of ::abs have been changed to call __builtin_fabs, which both Clang and GCC support.
show more ...
|
#
23368bee |
| 17-Feb-2020 |
Raphael Isemann <teemperor@gmail.com> |
Revert "[libc++] Move abs and div into stdlib.h to fix header cycle."
This reverts commit 82b47b2978405f802a33b00d046e6f18ef6a47be.
This broke Clang and LLDB module builds without -fmodules-local-s
Revert "[libc++] Move abs and div into stdlib.h to fix header cycle."
This reverts commit 82b47b2978405f802a33b00d046e6f18ef6a47be.
This broke Clang and LLDB module builds without -fmodules-local-submodule-visbility. I'll revert this for now until we have a fix and reland once Clang can properly handle this code.
See also the discussion in https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
show more ...
|