Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2 |
|
#
ba87515f |
| 12-Oct-2024 |
Nikolas Klauser <nikolasklauser@berlin.de> |
[libc++][RFC] Always define internal feature test macros (#89178)
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`
[libc++][RFC] Always define internal feature test macros (#89178)
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
show more ...
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
953af0e7 |
| 05-Sep-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++][NFC] Increase consistency for namespace closing comments
|
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, 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 |
|
#
4f215fdd |
| 06-Jan-2024 |
Konstantin Varlamov <varconsteq@gmail.com> |
[libc++][hardening] Categorize more assertions. (#75918)
Also introduce `_LIBCPP_ASSERT_PEDANTIC` for assertions violating which
results in a no-op or other benign behavior, but which may neverthel
[libc++][hardening] Categorize more assertions. (#75918)
Also introduce `_LIBCPP_ASSERT_PEDANTIC` for assertions violating which
results in a no-op or other benign behavior, but which may nevertheless
indicate a bug in the invoking code.
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 |
|
#
cd0ad421 |
| 27-Jun-2023 |
varconst <varconsteq@gmail.com> |
[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.
Replace most uses of `_LIBCPP_ASSERT` with `_LIBCPP_ASSERT_UNCATEGORIZED`.
This is done as a prerequisite to introducing hardened
[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.
Replace most uses of `_LIBCPP_ASSERT` with `_LIBCPP_ASSERT_UNCATEGORIZED`.
This is done as a prerequisite to introducing hardened mode to libc++. The idea is to make enabling assertions an opt-in with (somewhat) fine-grained controls over which categories of assertions are enabled. The vast majority of assertions are currently uncategorized; the new macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism for all kinds of assertions) without enabling all the uncategorized assertions (in the future; this patch preserves the current behavior).
Differential Revision: https://reviews.llvm.org/D153816
show more ...
|
Revision tags: llvmorg-16.0.6 |
|
#
21853b96 |
| 05-Jun-2023 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++][filesystem] Avoid using anonymous namespaces in support headers
This avoids using anonymous namespaces in headers and ensures that the various helper functions get deduplicated across the T
[libc++][filesystem] Avoid using anonymous namespaces in support headers
This avoids using anonymous namespaces in headers and ensures that the various helper functions get deduplicated across the TUs implementing <filesystem>. Otherwise, we'd get a definition of these helper functions in each TU where they are used, which is entirely unnecessary.
Differential Revision: https://reviews.llvm.org/D152378
show more ...
|
#
c7d3c844 |
| 12-Jun-2023 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Split sources for <filesystem>
The operations.cpp file contained the implementation of a ton of functionality unrelated to just the filesystem operations, and filesystem_common.h contained
[libc++] Split sources for <filesystem>
The operations.cpp file contained the implementation of a ton of functionality unrelated to just the filesystem operations, and filesystem_common.h contained a lot of unrelated functionality as well.
Splitting this up into more files will make it possible in the future to support parts of <filesystem> (e.g. path) on systems where there is no notion of a filesystem.
Differential Revision: https://reviews.llvm.org/D152377
show more ...
|