Buckets:
| // -*- C++ -*- | |
| //===----------------------------------------------------------------------===// | |
| // | |
| // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | |
| // See https://llvm.org/LICENSE.txt for license information. | |
| // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | |
| // | |
| //===----------------------------------------------------------------------===// | |
| // The attributes supported by clang are documented at https://clang.llvm.org/docs/AttributeReference.html | |
| // _LIBCPP_VERSION represents the version of libc++, which matches the version of LLVM. | |
| // Given a LLVM release LLVM XX.YY.ZZ (e.g. LLVM 17.0.1 == 17.00.01), _LIBCPP_VERSION is | |
| // defined to XXYYZZ. | |
| // NOLINTNEXTLINE(libcpp-cpp-version-check) | |
| // Incomplete features get their own specific disabling flags. This makes it | |
| // easier to grep for target specific flags once the feature is complete. | |
| // HARDENING { | |
| // TODO(LLVM 23): Remove this. We're making these an error to catch folks who might not have migrated. | |
| // Since hardening went through several changes (many of which impacted user-facing macros), | |
| // we're keeping these checks around for a bit longer than usual. Failure to properly configure | |
| // hardening results in checks being dropped silently, which is a pretty big deal. | |
| // The library provides the macro `_LIBCPP_HARDENING_MODE` which can be set to one of the following values: | |
| // | |
| // - `_LIBCPP_HARDENING_MODE_NONE`; | |
| // - `_LIBCPP_HARDENING_MODE_FAST`; | |
| // - `_LIBCPP_HARDENING_MODE_EXTENSIVE`; | |
| // - `_LIBCPP_HARDENING_MODE_DEBUG`. | |
| // | |
| // These values have the following effects: | |
| // | |
| // - `_LIBCPP_HARDENING_MODE_NONE` -- sets the hardening mode to "none" which disables all runtime hardening checks; | |
| // | |
| // - `_LIBCPP_HARDENING_MODE_FAST` -- sets that hardening mode to "fast". The fast mode enables security-critical checks | |
| // that can be done with relatively little runtime overhead in constant time; | |
| // | |
| // - `_LIBCPP_HARDENING_MODE_EXTENSIVE` -- sets the hardening mode to "extensive". The extensive mode is a superset of | |
| // the fast mode that additionally enables checks that are relatively cheap and prevent common types of logic errors | |
| // but are not necessarily security-critical; | |
| // | |
| // - `_LIBCPP_HARDENING_MODE_DEBUG` -- sets the hardening mode to "debug". The debug mode is a superset of the extensive | |
| // mode and enables all checks available in the library, including internal assertions. Checks that are part of the | |
| // debug mode can be very expensive and thus the debug mode is intended to be used for testing, not in production. | |
| // Inside the library, assertions are categorized so they can be cherry-picked based on the chosen hardening mode. These | |
| // macros are only for internal use -- users should only pick one of the high-level hardening modes described above. | |
| // | |
| // - `_LIBCPP_ASSERT_VALID_INPUT_RANGE` -- checks that ranges (whether expressed as an iterator pair, an iterator and | |
| // a sentinel, an iterator and a count, or a `std::range`) given as input to library functions are valid: | |
| // - the sentinel is reachable from the begin iterator; | |
| // - TODO(hardening): both iterators refer to the same container. | |
| // | |
| // - `_LIBCPP_ASSERT_VALID_ELEMENT_ACCESS` -- checks that any attempts to access a container element, whether through | |
| // the container object or through an iterator, are valid and do not attempt to go out of bounds or otherwise access | |
| // a non-existent element. For iterator checks to work, bounded iterators must be enabled in the ABI. Types like | |
| // `optional` and `function` are considered one-element containers for the purposes of this check. | |
| // | |
| // - `_LIBCPP_ASSERT_NON_NULL` -- checks that the pointer being dereferenced is not null. On most modern platforms zero | |
| // address does not refer to an actual location in memory, so a null pointer dereference would not compromize the | |
| // memory security of a program (however, it is still undefined behavior that can result in strange errors due to | |
| // compiler optimizations). | |
| // | |
| // - `_LIBCPP_ASSERT_NON_OVERLAPPING_RANGES` -- for functions that take several ranges as arguments, checks that the | |
| // given ranges do not overlap. | |
| // | |
| // - `_LIBCPP_ASSERT_VALID_DEALLOCATION` -- checks that an attempt to deallocate memory is valid (e.g. the given object | |
| // was allocated by the given allocator). Violating this category typically results in a memory leak. | |
| // | |
| // - `_LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL` -- checks that a call to an external API doesn't fail in | |
| // an unexpected manner. This includes triggering documented cases of undefined behavior in an external library (like | |
| // attempting to unlock an unlocked mutex in pthreads). Any API external to the library falls under this category | |
| // (from system calls to compiler intrinsics). We generally don't expect these failures to compromize memory safety or | |
| // otherwise create an immediate security issue. | |
| // | |
| // - `_LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR` -- checks any operations that exchange nodes between containers to make sure | |
| // the containers have compatible allocators. | |
| // | |
| // - `_LIBCPP_ASSERT_ARGUMENT_WITHIN_DOMAIN` -- checks that the given argument is within the domain of valid arguments | |
| // for the function. Violating this typically produces an incorrect result (e.g. the clamp algorithm returns the | |
| // original value without clamping it due to incorrect functors) or puts an object into an invalid state (e.g. | |
| // a string view where only a subset of elements is possible to access). This category is for assertions violating | |
| // which doesn't cause any immediate issues in the library -- whatever the consequences are, they will happen in the | |
| // user code. | |
| // | |
| // - `_LIBCPP_ASSERT_PEDANTIC` -- checks prerequisites which are imposed by the Standard, but violating which happens to | |
| // be benign in our implementation. | |
| // | |
| // - `_LIBCPP_ASSERT_SEMANTIC_REQUIREMENT` -- checks that the given argument satisfies the semantic requirements imposed | |
| // by the Standard. Typically, there is no simple way to completely prove that a semantic requirement is satisfied; | |
| // thus, this would often be a heuristic check and it might be quite expensive. | |
| // | |
| // - `_LIBCPP_ASSERT_INTERNAL` -- checks that internal invariants of the library hold. These assertions don't depend on | |
| // user input. | |
| // | |
| // - `_LIBCPP_ASSERT_UNCATEGORIZED` -- for assertions that haven't been properly classified yet. | |
| // clang-format off | |
| // clang-format on | |
| // Hardening assertion semantics generally mirror the evaluation semantics of C++26 Contracts: | |
| // - `ignore` evaluates the assertion but doesn't do anything if it fails (note that it differs from the Contracts | |
| // `ignore` semantic which wouldn't evaluate the assertion at all); | |
| // - `observe` logs an error (indicating, if possible, that the error is fatal) and continues execution; | |
| // - `quick-enforce` terminates the program as fast as possible (via trapping); | |
| // - `enforce` logs an error and then terminates the program. | |
| // | |
| // Notes: | |
| // - Continuing execution after a hardening check fails results in undefined behavior; the `observe` semantic is meant | |
| // to make adopting hardening easier but should not be used outside of this scenario; | |
| // - C++26 wording for Library Hardening precludes a conforming Hardened implementation from using the Contracts | |
| // `ignore` semantic when evaluating hardened preconditions in the Library. Libc++ allows using this semantic for | |
| // hardened preconditions, however, be aware that using `ignore` does not produce a conforming "Hardened" | |
| // implementation, unlike the other semantics above. | |
| // clang-format off | |
| // clang-format on | |
| // Allow users to define an arbitrary assertion semantic; otherwise, use the default mapping from modes to semantics. | |
| // The default is for production-capable modes to use `quick-enforce` (i.e., trap) and for the `debug` mode to use | |
| // `enforce` (i.e., log and abort). | |
| // } HARDENING | |
| // This checks wheter a Clang module is built | |
| // '__is_identifier' returns '0' if '__x' is a reserved identifier provided by | |
| // the compiler and '1' otherwise. | |
| // Both MinGW and native MSVC provide a "MSVC"-like environment | |
| // If mingw not explicitly detected, assume using MS C runtime only if | |
| // a MS compatibility version is specified. | |
| // The size of wchar is 2 byte on 32-bit mode on AIX. | |
| // Libc++ supports various implementations of std::random_device. | |
| // | |
| // _LIBCPP_USING_DEV_RANDOM | |
| // Read entropy from the given file, by default `/dev/urandom`. | |
| // If a token is provided, it is assumed to be the path to a file | |
| // to read entropy from. This is the default behavior if nothing | |
| // else is specified. This implementation requires storing state | |
| // inside `std::random_device`. | |
| // | |
| // _LIBCPP_USING_ARC4_RANDOM | |
| // Use arc4random(). This allows obtaining random data even when | |
| // using sandboxing mechanisms. On some platforms like Apple, this | |
| // is the recommended source of entropy for user-space programs. | |
| // When this option is used, the token passed to `std::random_device`'s | |
| // constructor *must* be "/dev/urandom" -- anything else is an error. | |
| // | |
| // _LIBCPP_USING_GETENTROPY | |
| // Use getentropy(). | |
| // When this option is used, the token passed to `std::random_device`'s | |
| // constructor *must* be "/dev/urandom" -- anything else is an error. | |
| // | |
| // _LIBCPP_USING_FUCHSIA_CPRNG | |
| // Use Fuchsia's zx_cprng_draw() system call, which is specified to | |
| // deliver high-quality entropy and cannot fail. | |
| // When this option is used, the token passed to `std::random_device`'s | |
| // constructor *must* be "/dev/urandom" -- anything else is an error. | |
| // | |
| // _LIBCPP_USING_NACL_RANDOM | |
| // NaCl's sandbox (which PNaCl also runs in) doesn't allow filesystem access, | |
| // including accesses to the special files under `/dev`. This implementation | |
| // uses the NaCL syscall `nacl_secure_random_init()` to get entropy. | |
| // When this option is used, the token passed to `std::random_device`'s | |
| // constructor *must* be "/dev/urandom" -- anything else is an error. | |
| // | |
| // _LIBCPP_USING_WIN32_RANDOM | |
| // Use rand_s(), for use on Windows. | |
| // When this option is used, the token passed to `std::random_device`'s | |
| // constructor *must* be "/dev/urandom" -- anything else is an error. | |
| typedef __char16_t char16_t; | |
| typedef __char32_t char32_t; | |
| // TODO: Make this a proper customization point or remove the option to override it. | |
| // Try to approximate the effect of exclude_from_explicit_instantiation | |
| // (which is that entities are not assumed to be provided by explicit | |
| // template instantiations in the dylib) by always inlining those entities. | |
| // This macro marks a symbol as being hidden from libc++'s ABI. This is achieved | |
| // on two levels: | |
| // 1. The symbol is given hidden visibility, which ensures that users won't start exporting | |
| // symbols from their dynamic library by means of using the libc++ headers. This ensures | |
| // that those symbols stay private to the dynamic library in which it is defined. | |
| // | |
| // 2. The symbol is given an ABI tag that encodes the ODR-relevant properties of the library. | |
| // This ensures that no ODR violation can arise from mixing two TUs compiled with different | |
| // versions or configurations of libc++ (such as exceptions vs no-exceptions). Indeed, if the | |
| // program contains two definitions of a function, the ODR requires them to be token-by-token | |
| // equivalent, and the linker is allowed to pick either definition and discard the other one. | |
| // | |
| // For example, if a program contains a copy of `vector::at()` compiled with exceptions enabled | |
| // *and* a copy of `vector::at()` compiled with exceptions disabled (by means of having two TUs | |
| // compiled with different settings), the two definitions are both visible by the linker and they | |
| // have the same name, but they have a meaningfully different implementation (one throws an exception | |
| // and the other aborts the program). This violates the ODR and makes the program ill-formed, and in | |
| // practice what will happen is that the linker will pick one of the definitions at random and will | |
| // discard the other one. This can quite clearly lead to incorrect program behavior. | |
| // | |
| // A similar reasoning holds for many other properties that are ODR-affecting. Essentially any | |
| // property that causes the code of a function to differ from the code in another configuration | |
| // can be considered ODR-affecting. In practice, we don't encode all such properties in the ABI | |
| // tag, but we encode the ones that we think are most important: library version, exceptions, and | |
| // hardening mode. | |
| // | |
| // Note that historically, solving this problem has been achieved in various ways, including | |
| // force-inlining all functions or giving internal linkage to all functions. Both these previous | |
| // solutions suffer from drawbacks that lead notably to code bloat. | |
| // | |
| // Note that we use _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION to ensure that we don't depend | |
| // on _LIBCPP_HIDE_FROM_ABI methods of classes explicitly instantiated in the dynamic library. | |
| // | |
| // Also note that the _LIBCPP_HIDE_FROM_ABI_VIRTUAL macro should be used on virtual functions | |
| // instead of _LIBCPP_HIDE_FROM_ABI. That macro does not use an ABI tag. Indeed, the mangled | |
| // name of a virtual function is part of its ABI, since some architectures like arm64e can sign | |
| // the virtual function pointer in the vtable based on the mangled name of the function. Since | |
| // we use an ABI tag that changes with each released version, the mangled name of the virtual | |
| // function would change, which is incorrect. Note that it doesn't make much sense to change | |
| // the implementation of a virtual function in an ABI-incompatible way in the first place, | |
| // since that would be an ABI break anyway. Hence, the lack of ABI tag should not be noticeable. | |
| // | |
| // The macro can be applied to record and enum types. When the tagged type is nested in | |
| // a record this "parent" record needs to have the macro too. Another use case for applying | |
| // this macro to records and unions is to apply an ABI tag to inline constexpr variables. | |
| // This can be useful for inline variables that are implementation details which are expected | |
| // to change in the future. | |
| // | |
| // TODO: We provide a escape hatch with _LIBCPP_NO_ABI_TAG for folks who want to avoid increasing | |
| // the length of symbols with an ABI tag. In practice, we should remove the escape hatch and | |
| // use compression mangling instead, see https://github.com/itanium-cxx-abi/cxx-abi/issues/70. | |
| // Clang modules take a significant compile time hit when pushing and popping diagnostics. | |
| // Since all the headers are marked as system headers unless _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER is defined, we can | |
| // simply disable this pushing and popping when _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER isn't defined. | |
| // clang-format off | |
| // The unversioned namespace is used when we want to be ABI compatible with other standard libraries in some way. There | |
| // are two main categories where that's the case: | |
| // - Historically, we have made exception types ABI compatible with libstdc++ to allow throwing them between libstdc++ | |
| // and libc++. This is not used anymore for new exception types, since there is no use-case for it anymore. | |
| // - Types and functions which are used by the compiler are in the unversioned namespace, since the compiler has to know | |
| // their mangling without the appropriate declaration in some cases. | |
| // If it's not clear whether using the unversioned namespace is the correct thing to do, it's not. The versioned | |
| // namespace (_LIBCPP_BEGIN_NAMESPACE_STD) should almost always be used. | |
| // TODO: This should really be in the versioned namespace | |
| // clang-format on | |
| // clang-format off | |
| // clang-format on | |
| // If we are getting operator new from the MSVC CRT, then allocation overloads | |
| // for align_val_t were added in 19.12, aka VS 2017 version 15.3. | |
| // We're deferring to Microsoft's STL to provide aligned new et al. We don't | |
| // have it unless the language feature test macro is defined. | |
| // It is not yet possible to use aligned_alloc() on all Apple platforms since | |
| // 10.15 was the first version to ship an implementation of aligned_alloc(). | |
| // Android only provides aligned_alloc when targeting API 28 or higher. | |
| // Deprecation macros. | |
| // | |
| // Deprecations warnings are always enabled, except when users explicitly opt-out | |
| // by defining _LIBCPP_DISABLE_DEPRECATION_WARNINGS. | |
| // Macros to enter and leave a state where deprecation warnings are suppressed. | |
| // Thread API | |
| // clang-format off | |
| // clang-format on | |
| // TODO(44575): Switch to C11 thread API when possible. | |
| // The glibc and Bionic implementation of pthreads implements | |
| // pthread_mutex_destroy as nop for regular mutexes. Additionally, Win32 | |
| // mutexes have no destroy mechanism. | |
| // | |
| // This optimization can't be performed on Apple platforms, where | |
| // pthread_mutex_destroy can allow the kernel to release resources. | |
| // See https://llvm.org/D64298 for details. | |
| // | |
| // TODO(EricWF): Enable this optimization on Bionic after speaking to their | |
| // respective stakeholders. | |
| // clang-format off | |
| // clang-format on | |
| // Destroying a condvar is a nop on Windows. | |
| // | |
| // This optimization can't be performed on Apple platforms, where | |
| // pthread_cond_destroy can allow the kernel to release resources. | |
| // See https://llvm.org/D64298 for details. | |
| // | |
| // TODO(EricWF): This is potentially true for some pthread implementations | |
| // as well. | |
| // The CUDA SDK contains an unfortunate definition for the __noinline__ macro, | |
| // which breaks the regular __attribute__((__noinline__)) syntax. Therefore, | |
| // when compiling for CUDA we use the non-underscored version of the noinline | |
| // attribute. | |
| // | |
| // This is a temporary workaround and we still expect the CUDA SDK team to solve | |
| // this issue properly in the SDK headers. | |
| // | |
| // See https://github.com/llvm/llvm-project/pull/73838 for more details. | |
| // We often repeat things just for handling wide characters in the library. | |
| // When wide characters are disabled, it can be useful to have a quick way of | |
| // disabling it without having to resort to #if-#endif, which has a larger | |
| // impact on readability. | |
| // clang-format off | |
| // clang-format on | |
| // Configures the fopen close-on-exec mode character, if any. This string will | |
| // be appended to any mode string used by fstream for fopen/fdopen. | |
| // | |
| // Not all platforms support this, but it helps avoid fd-leaks on platforms that | |
| // do. | |
| // MSVC implements [[no_unique_address]] as a silent no-op currently. | |
| // (If/when MSVC breaks its C++ ABI, it will be changed to work as intended.) | |
| // However, MSVC implements [[msvc::no_unique_address]] which does what | |
| // [[no_unique_address]] is supposed to do, in general. | |
| // c8rtomb() and mbrtoc8() were added in C++20 and C23. Support for these | |
| // functions is gradually being added to existing C libraries. The conditions | |
| // below check for known C library versions and conditions under which these | |
| // functions are declared by the C library. | |
| // | |
| // GNU libc 2.36 and newer declare c8rtomb() and mbrtoc8() in C++ modes if | |
| // __cpp_char8_t is defined or if C2X extensions are enabled. Determining | |
| // the latter depends on internal GNU libc details that are not appropriate | |
| // to depend on here, so any declarations present when __cpp_char8_t is not | |
| // defined are ignored. | |
| // There are a handful of public standard library types that are intended to | |
| // support CTAD but don't need any explicit deduction guides to do so. This | |
| // macro is used to mark them as such, which suppresses the | |
| // '-Wctad-maybe-unsupported' compiler warning when CTAD is used in user code | |
| // with these classes. | |
| // TODO(LLVM 22): Remove the workaround | |
| // Enable SIMD for compilers that support OpenMP 4.0 | |
| // Declaration of reduction functor, where | |
| // NAME - the name of the functor | |
| // OP - type of the callable object with the reduction operation | |
| // omp_in - refers to the local partial result | |
| // omp_out - refers to the final value of the combiner operator | |
| // omp_priv - refers to the private copy of the initial value | |
| // omp_orig - refers to the original variable to be reduced | |
| // Optional attributes - these are useful for a better QoI, but not required to be available | |
| // Allow for build-time disabling of unsigned integer sanitization | |
| // TODO(LLVM 22): Remove this macro once LLVM19 support ends. __cpp_explicit_this_parameter has been set in LLVM20. | |
| // Clang-18 has support for deducing this, but it does not set the FTM. | |
Xet Storage Details
- Size:
- 57.3 kB
- Xet hash:
- a5c38e79c138eb23cdf10a8f1cac7920c01d0206cf90a8298a83ad1aa0fe017f
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.