20 Commits

Author SHA1 Message Date
Louis Dionne
3c4b673af0
[libc++] Fix -Wgnu-include-next in stddef.h (#88214)
As reported in #86843, we must have #pragma GCC system_header before we
use #include_next, otherwise the compiler may not understand that we're
in a system header and may issue a diagnostic for our usage of
2024-04-11 12:36:56 -04:00
Louis Dionne
2950283ddd
[libc++] Simplify the implementation of <stddef.h> (#86843)
Libc++'s own <stddef.h> is complicated by the need to handle various
platform-specific macros and to support duplicate inclusion. In reality,
we only need to add a declaration of nullptr_t to it, so we can simply
include the underlying <stddef.h> outside of our guards to let it handle
re-inclusion itself.
2024-04-02 08:14:04 -04:00
Louis Dionne
9783f28cbb
[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
2023-12-18 14:01:33 -05:00
Yi Kong
3f65c8fcbe Revert "[libc++] Remove workarounds for systems that used to require __need_XXX macros"
This reverts commit 119cef40d18c48240854edc553dca61c4e9fdf27.

The change broke multiple builders.
2022-11-22 20:46:38 +09:00
Louis Dionne
119cef40d1 [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
2022-11-21 08:22:09 -05:00
Louis Dionne
5d87f60f89 [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
2022-11-17 10:30:20 -05:00
Nico Weber
674729813e 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
2022-11-15 11:35:00 -05:00
Louis Dionne
226409c628 [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
2022-11-15 10:58:11 -05:00
Louis Dionne
157bbe6aea [libc++] Remove the ability to use the std::nullptr_t emulation in C++03 mode
Back in https://reviews.llvm.org/D109459, we stopped using the C++03
emulation for std::nullptr_t by default, which was an ABI break. We
still left a knob for users to turn it back on if they were broken by
the change, with a note that we would remove that knob after one release.

The time has now come to remove the knob and clean up the std::nullptr_t
emulation.

Differential Revision: https://reviews.llvm.org/D114786
2022-02-07 17:51:05 -05:00
Arthur O'Dwyer
fa6b9e4010 [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
2022-02-04 12:27:19 -05:00
Louis Dionne
eb8650a757 [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.
2021-11-17 16:30:52 -05:00
Louis Dionne
4cd6ca102a [libc++] NFC: Normalize #endif // comment indentation 2021-04-20 12:03:32 -04:00
Joerg Sonnenberger
98f77828a9 Avoid using std::max_align_t in pre-C++11 mode
Always depend on the compiler to have a correct implementation of
max_align_t in stddef.h and don't provide a fallback. For pre-C++11,
require __STDCPP_NEW_ALIGNMENT__ in <new> as provided by clang in all
standard modes. Adjust test cases to avoid testing or using max_align_t
in pre-C++11 mode and also to better deal with alignof(max_align_t)>16.
Document requirements of the alignment tests around natural alignment of
power-of-two-sized types.

Differential revision: https://reviews.llvm.org/D73245
2020-04-04 01:38:41 +02:00
Louis Dionne
7c2f4a8370 [libc++] Revert 03dd205c151 "Adjust max_align_t handling"
That commit was made without approval from a libc++ reviewer, and it
also broke the build in C++03 mode.
2020-02-25 11:42:08 -05:00
Joerg Sonnenberger
03dd205c15 Adjust max_align_t handling
Depend on the compiler to provide a correct implementation of
max_align_t. If __STDCPP_NEW_ALIGNMENT__ is missing and C++03 mode has
been explicitly enabled, provide a minimal fallback in <new> as
alignment of the largest primitive types.
2020-02-25 01:36:43 +01:00
Chandler Carruth
57b08b0944 Update more file headers across all of the LLVM projects in the monorepo
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
2019-01-19 10:56:40 +00:00
Kamil Rytarowski
22c9256a49 Teach libc++ to use native NetBSD's max_align_t
Summary:
The NetBSD headers ship with max_align_t, that is not
compatible with the fallback version in libc++.

There is no defined a compiler specific symbol in the headers like:
 - __CLANG_MAX_ALIGN_T_DEFINED
 - _GCC_MAX_ALIGN_T
 - __DEFINED_max_align_t

Sponsored by <The NetBSD Foundation>

Reviewers: chandlerc, dlj, EricWF, joerg

Reviewed By: joerg

Subscribers: bsdjhb, llvm-commits, cfe-commits

Differential Revision: https://reviews.llvm.org/D47814

llvm-svn: 340224
2018-08-20 22:29:20 +00:00
David L. Jones
4b22736222 Check for musl-libc's max_align_t in addition to other variants.
Summary:
Libcxx will define its own max_align_t when it is not available. However, the
availability checks today only check for Clang's definition and GCC's
definition. In particular, it does not check for musl's definition, which is the
same as GCC's but guarded with a different macro.

Reviewers: mclow.lists, EricWF

Reviewed By: EricWF

Subscribers: chandlerc, cfe-commits

Differential Revision: https://reviews.llvm.org/D28478

llvm-svn: 294683
2017-02-10 01:27:42 +00:00
Richard Smith
2999ea0f04 PR25118: move system_header pragma before uses of include_next to avoid extension warnings for people finding libc++ headers via -I paths.
llvm-svn: 249788
2015-10-09 00:26:50 +00:00
Richard Smith
d6cffc4fe0 Split <stddef.h> out of <cstddef>.
There are a bunch of macros (__need_size_t etc) that request just one piece of
<stddef.h>; if any one of these is defined, we just directly include the
underlying header.

Note that <stddef.h> provides a ::nullptr_t. We don't want that available to
includers of <cstddef>, so instead of following the usual pattern where <cfoo>
includes <foo.h> then pulls things from :: into std:: with using-declarations,
we implement <stddef.h> and <cstddef> separately; both include <__nullptr> for
the definition of std::nullptr_t.

llvm-svn: 249761
2015-10-08 22:25:27 +00:00