11 Commits

Author SHA1 Message Date
Nikolas Klauser
b9a2658a3e
[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.
2024-12-21 13:01:48 +01:00
Nikolas Klauser
c166a9c713
[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.
2024-12-10 16:02:12 +01: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
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
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
Eric Fiselier
0706e144d5 Mark fenv.h as a system header before the #include_next directive
This fixes a -Wgnu-include-next warning

Patch by dmauro.

llvm-svn: 357267
2019-03-29 16:03:57 +00:00
Eric Fiselier
9ebc9dbd3c Don't declare fenv.h functions when they're a macro.
libc still provides function declarations, and these declarations
conflict with libc++'s

llvm-svn: 353774
2019-02-12 00:05:14 +00:00
Eric Fiselier
cf39dd44b8 Add fenv.h header
Summary:
Some implementations of fenv.h use macros to define the functions they provide. This can cause problems when `std::fegetround()` is spelled in source.

This patch adds a `fenv.h` header to libc++ for the sole purpose of turning those macros into real functions.

Reviewers: rsmith, mclow.lists, ldionne

Reviewed By: rsmith

Subscribers: mgorny, christof, libcxx-commits

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

llvm-svn: 353767
2019-02-11 23:47:19 +00:00