summaryrefslogtreecommitdiff
path: root/libcxx/include/cstdint
AgeCommit message (Collapse)Author
2024-12-21[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)Nikolas Klauser
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-10[libc++] Add #if 0 block to all the top-level headers (#119234)Nikolas Klauser
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-11-06[libc++] Only include the system <stdint.h> and <locale.h> if they exist ↵Louis Dionne
(#115017) Prior to aa7f377c96, we only did an #include_next of those system headers if they existed. After removing those headers from libc++, we started assuming that the system provided the headers because we unconditionally started including them. This patch fixes that.
2024-10-20[libc++] Remove libc++'s own stdint.h and locale.h (#107436)Louis Dionne
These headers are not doing anything beyond the system or compiler provided equivalent headers, so there's no real reason to keep them around. Reducing the number of C headers we provide in libc++ simplifies our header layering and reduces the potential for confusion when headers are layered incorrectly.
2024-02-29[libc++] Clean up includes of <__assert> (#80091)Louis Dionne
Originally, we used __libcpp_verbose_abort to handle assertion failures. That function was declared from all public headers. Since we don't use that mechanism anymore, we don't need to declare __libcpp_verbose_abort from all public headers, and we can clean up a lot of unnecessary includes. This patch also moves the definition of the various assertion categories to the <__assert> header, since we now rely on regular IWYU for these assertion macros. rdar://105510916
2022-08-17[libc++] Diagnose when header search paths are set up incorrectlyLouis Dionne
An issue I often see in codebases compiled for unusual platforms is that header search paths are specified manually and are subtly wrong. For example, people will manually add `-isystem <some-toolchain>/usr/include`, which ends up messing up the layering of header search paths required by libc++ (because the C Standard Library now appears *before* libc++ in the search paths). Without this patch, this will end up causing compilation errors that are pretty inscrutable. This patch aims to improve the user experience by diagnosing this issue explicitly. In all cases I can think of, I would expect that a compilation error occur if these header search paths are not layered properly. This should only provide an explicit diagnostic instead of failing due to seemingly unrelated compilation errors. Differential Revision: https://reviews.llvm.org/D131441
2022-03-30[libc++] Ensure that all public C++ headers include <__assert>Louis Dionne
This patch changes the requirement for getting the declaration of the assertion handler from including <__assert> to including any public C++ header of the library. Note that C compatibility headers are excluded because we don't implement all the C headers ourselves -- some of them are taken straight from the C library, like assert.h. It also adds a generated test to check it. Furthermore, this new generated test is designed in a way that will make it possible to replace almost all the existing test-generation scripts with this system in upcoming patches. Differential Revision: https://reviews.llvm.org/D122506
2022-02-04[libc++] Normalize all our '#pragma GCC system_header', and regression-test.Arthur O'Dwyer
Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800
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.
2021-06-04[libc++] Use the using_if_exists attribute when providedLouis Dionne
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when the compiler supports it. This makes it easier to port libc++ on top of new platforms that don't fully support the C Standard library. Previously, libc++ would fail to build when trying to import a missing declaration in a <cXXXX> header. With the attribute, the declaration will simply not be imported into namespace std, and hence it won't be available for libc++ to use. In many cases, the declarations were *not* actually required for libc++ to work (they were only surfaced for users to use them as std::XXXX), so not importing them into namespace std is acceptable. The same thing could be achieved by conscious usage of `#ifdef` along with platform detection, however that quickly creates a maintenance problem as libc++ is ported to new platforms. Furthermore, this problem is exacerbated when mixed with vendor internal-only platforms, which can lead to difficulties maintaining a downstream fork of the library. For the time being, we only use the using_if_exists attribute when it is supported. At some point in the future, we will start removing #ifdef paths that are unnecessary when the attribute is supported, and folks who need those #ifdef paths will be required to use a compiler that supports the attribute. [1]: http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html Differential Revision: https://reviews.llvm.org/D90257
2021-04-20[libc++] NFC: Normalize `#endif //` comment indentationLouis Dionne
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
2011-10-17Windows support by Ruben Van Boxem.Howard Hinnant
llvm-svn: 142235
2010-11-16license changeHoward Hinnant
llvm-svn: 119395
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