History log of /llvm-project/libcxx/include/stdlib.h (Results 1 – 25 of 31)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12