2010-05-11 19:42:16 +00:00
|
|
|
// -*- C++ -*-
|
2021-11-17 16:25:01 -05:00
|
|
|
//===----------------------------------------------------------------------===//
|
2010-05-11 19:42:16 +00:00
|
|
|
//
|
2019-01-19 10:56:40 +00:00
|
|
|
// 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
|
2010-05-11 19:42:16 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2022-03-23 13:11:04 -04:00
|
|
|
#ifndef _LIBCPP___CONFIG
|
|
|
|
#define _LIBCPP___CONFIG
|
2010-05-11 19:42:16 +00:00
|
|
|
|
2020-06-26 12:08:59 -04:00
|
|
|
#include <__config_site>
|
2024-05-28 07:22:06 -04:00
|
|
|
#include <__configuration/abi.h>
|
2024-05-28 18:29:11 -07:00
|
|
|
#include <__configuration/availability.h>
|
2024-05-28 07:22:06 -04:00
|
|
|
#include <__configuration/compiler.h>
|
2024-10-31 11:35:30 -04:00
|
|
|
#include <__configuration/language.h>
|
2024-05-28 07:22:06 -04:00
|
|
|
#include <__configuration/platform.h>
|
2020-06-26 12:08:59 -04:00
|
|
|
|
2015-11-06 06:30:12 +00:00
|
|
|
#ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
|
2022-02-01 20:16:40 -05:00
|
|
|
# pragma GCC system_header
|
2011-10-17 20:05:10 +00:00
|
|
|
#endif
|
2010-05-11 19:42:16 +00:00
|
|
|
|
2015-11-06 06:30:12 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
2023-06-07 13:33:02 -07:00
|
|
|
// The attributes supported by clang are documented at https://clang.llvm.org/docs/AttributeReference.html
|
|
|
|
|
2022-09-19 11:27:50 -04:00
|
|
|
// _LIBCPP_VERSION represents the version of libc++, which matches the version of LLVM.
|
2023-01-24 22:55:53 -08:00
|
|
|
// Given a LLVM release LLVM XX.YY.ZZ (e.g. LLVM 17.0.1 == 17.00.01), _LIBCPP_VERSION is
|
2022-09-19 15:38:18 -04:00
|
|
|
// defined to XXYYZZ.
|
2025-01-28 19:48:43 -08:00
|
|
|
# define _LIBCPP_VERSION 210000
|
2010-05-11 19:42:16 +00:00
|
|
|
|
2022-07-07 14:07:37 -04:00
|
|
|
# define _LIBCPP_CONCAT_IMPL(_X, _Y) _X##_Y
|
|
|
|
# define _LIBCPP_CONCAT(_X, _Y) _LIBCPP_CONCAT_IMPL(_X, _Y)
|
2024-09-16 11:08:57 +02:00
|
|
|
# define _LIBCPP_CONCAT3(X, Y, Z) _LIBCPP_CONCAT(X, _LIBCPP_CONCAT(Y, Z))
|
2022-07-07 14:07:37 -04:00
|
|
|
|
2020-09-02 12:22:29 -04:00
|
|
|
# if __STDC_HOSTED__ == 0
|
2019-03-05 18:40:49 +00:00
|
|
|
# define _LIBCPP_FREESTANDING
|
|
|
|
# endif
|
|
|
|
|
2023-07-12 10:12:51 -07:00
|
|
|
// HARDENING {
|
|
|
|
|
2024-10-29 10:48:18 -04:00
|
|
|
// TODO: Remove in LLVM 21. We're making this an error to catch folks who might not have migrated.
|
2023-07-14 16:58:15 -07:00
|
|
|
# ifdef _LIBCPP_ENABLE_ASSERTIONS
|
2024-10-29 10:48:18 -04:00
|
|
|
# error "_LIBCPP_ENABLE_ASSERTIONS has been removed, please use _LIBCPP_HARDENING_MODE instead"
|
2023-07-14 16:58:15 -07:00
|
|
|
# endif
|
|
|
|
|
2023-11-08 09:10:00 -10:00
|
|
|
// The library provides the macro `_LIBCPP_HARDENING_MODE` which can be set to one of the following values:
|
2023-07-12 10:12:51 -07:00
|
|
|
//
|
2023-11-08 09:10:00 -10:00
|
|
|
// - `_LIBCPP_HARDENING_MODE_NONE`;
|
|
|
|
// - `_LIBCPP_HARDENING_MODE_FAST`;
|
|
|
|
// - `_LIBCPP_HARDENING_MODE_EXTENSIVE`;
|
|
|
|
// - `_LIBCPP_HARDENING_MODE_DEBUG`.
|
2023-09-12 12:01:36 -07:00
|
|
|
//
|
2023-11-08 09:10:00 -10:00
|
|
|
// 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;
|
2023-07-12 10:12:51 -07:00
|
|
|
//
|
2023-11-08 09:10:00 -10:00
|
|
|
// - `_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.
|
2023-07-12 10:12:51 -07:00
|
|
|
|
2023-07-20 10:13:54 -07:00
|
|
|
// 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.
|
|
|
|
//
|
2023-11-07 16:12:15 -10:00
|
|
|
// - `_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).
|
|
|
|
//
|
2023-07-24 14:56:44 -07:00
|
|
|
// - `_LIBCPP_ASSERT_NON_OVERLAPPING_RANGES` -- for functions that take several ranges as arguments, checks that the
|
|
|
|
// given ranges do not overlap.
|
|
|
|
//
|
2024-01-22 18:12:58 -08:00
|
|
|
// - `_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.
|
|
|
|
//
|
2023-07-20 10:13:54 -07:00
|
|
|
// - `_LIBCPP_ASSERT_COMPATIBLE_ALLOCATOR` -- checks any operations that exchange nodes between containers to make sure
|
|
|
|
// the containers have compatible allocators.
|
|
|
|
//
|
2024-01-20 23:38:02 -08:00
|
|
|
// - `_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.
|
|
|
|
//
|
2024-01-05 16:29:23 -08:00
|
|
|
// - `_LIBCPP_ASSERT_PEDANTIC` -- checks prerequisites which are imposed by the Standard, but violating which happens to
|
|
|
|
// be benign in our implementation.
|
|
|
|
//
|
[libc++][hardening] Categorize assertions related to strict weak ordering (#77405)
If a user passes a comparator that doesn't satisfy strict weak ordering
(see https://eel.is/c++draft/algorithms#alg.sorting.general) to
a sorting algorithm, the algorithm can produce an incorrect result or
even lead
to an out-of-bounds access. Unfortunately, comprehensively validating
that a given comparator indeed satisfies the strict weak ordering
requirement is prohibitively expensive (see [the related
RFC](https://discourse.llvm.org/t/rfc-strict-weak-ordering-checks-in-the-debug-libc/70217)).
As a result, we have three independent sets of checks:
- assertions that catch out-of-bounds accesses within the algorithms'
implementation. These are relatively cheap; however, they cannot catch
the underlying cause and cannot prevent the case where an invalid
comparator would result in an incorrectly-sorted sequence without
actually triggering an OOB access;
- debug comparators that wrap a given comparator and on each comparison
check that if `(a < b)`, then `!(b < a)`, where `<` stands for the
user-provided comparator. This performs up to 2x number of comparisons
but doesn't affect the algorithmic complexity. While this approach can
find more issues, it is still a heuristic;
- a comprehensive check of the comparator that validates up to 100
elements in the resulting sorted sequence (see the RFC above for
details). The check is expensive but the 100 element limit can somewhat
compensate for that, especially for large values of `N`.
The first set of checks is enabled in the fast hardening mode while the
other two are only enabled in the debug mode.
This patch also removes the
`_LIBCPP_DEBUG_STRICT_WEAK_ORDERING_CHECK` macro that
previously was used to selectively enable the 100-element check.
Now this check is enabled unconditionally in the debug mode.
Also, introduce a new category
`_LIBCPP_ASSERT_SEMANTIC_REQUIREMENT`. This category is
intended for checking the semantic requirements from the Standard.
Typically, these are hard or impossible to completely validate, so
these checks are expected to be heuristic in nature and potentially
quite expensive.
See https://reviews.llvm.org/D150264 for additional background.
Fixes #71496
2024-01-22 23:31:58 -08:00
|
|
|
// - `_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.
|
|
|
|
//
|
2023-07-20 10:13:54 -07:00
|
|
|
// - `_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.
|
2023-07-12 10:12:51 -07:00
|
|
|
|
2023-11-08 09:10:00 -10:00
|
|
|
// clang-format off
|
|
|
|
# define _LIBCPP_HARDENING_MODE_NONE (1 << 1)
|
|
|
|
# define _LIBCPP_HARDENING_MODE_FAST (1 << 2)
|
|
|
|
# define _LIBCPP_HARDENING_MODE_EXTENSIVE (1 << 4) // Deliberately not ordered.
|
|
|
|
# define _LIBCPP_HARDENING_MODE_DEBUG (1 << 3)
|
|
|
|
// clang-format on
|
2023-09-12 12:01:36 -07:00
|
|
|
|
2023-11-08 09:10:00 -10:00
|
|
|
# ifndef _LIBCPP_HARDENING_MODE
|
2024-02-06 13:45:31 -08:00
|
|
|
|
|
|
|
# ifndef _LIBCPP_HARDENING_MODE_DEFAULT
|
|
|
|
# error _LIBCPP_HARDENING_MODE_DEFAULT is not defined. This definition should be set at configuration time in the \
|
|
|
|
`__config_site` header, please make sure your installation of libc++ is not broken.
|
|
|
|
# endif
|
|
|
|
|
2023-11-08 09:10:00 -10:00
|
|
|
# define _LIBCPP_HARDENING_MODE _LIBCPP_HARDENING_MODE_DEFAULT
|
2023-07-12 10:12:51 -07:00
|
|
|
# endif
|
|
|
|
|
2023-11-08 09:10:00 -10:00
|
|
|
# if _LIBCPP_HARDENING_MODE != _LIBCPP_HARDENING_MODE_NONE && \
|
|
|
|
_LIBCPP_HARDENING_MODE != _LIBCPP_HARDENING_MODE_FAST && \
|
|
|
|
_LIBCPP_HARDENING_MODE != _LIBCPP_HARDENING_MODE_EXTENSIVE && \
|
|
|
|
_LIBCPP_HARDENING_MODE != _LIBCPP_HARDENING_MODE_DEBUG
|
|
|
|
# error _LIBCPP_HARDENING_MODE must be set to one of the following values: \
|
|
|
|
_LIBCPP_HARDENING_MODE_NONE, \
|
|
|
|
_LIBCPP_HARDENING_MODE_FAST, \
|
|
|
|
_LIBCPP_HARDENING_MODE_EXTENSIVE, \
|
|
|
|
_LIBCPP_HARDENING_MODE_DEBUG
|
2023-07-12 10:12:51 -07:00
|
|
|
# endif
|
|
|
|
|
|
|
|
// } HARDENING
|
|
|
|
|
2022-08-13 13:52:35 +02:00
|
|
|
# define _LIBCPP_TOSTRING2(x) #x
|
2022-02-14 18:52:28 +01:00
|
|
|
# define _LIBCPP_TOSTRING(x) _LIBCPP_TOSTRING2(x)
|
|
|
|
|
2023-02-17 14:01:19 +01:00
|
|
|
// NOLINTNEXTLINE(libcpp-cpp-version-check)
|
2016-09-25 03:34:28 +00:00
|
|
|
# if __cplusplus < 201103L
|
|
|
|
# define _LIBCPP_CXX03_LANG
|
|
|
|
# endif
|
2015-07-10 20:26:38 +00:00
|
|
|
|
[libc++] [C++20] [P0415] Constexpr for std::complex.
This patch adds constexpr to <complex> header: operators, member operators, and member functions (real, imag, norm, conj).
https://eel.is/c++draft/complex.numbers
https://wg21.link/p0415
Reviewed By: ldionne, #libc
Spies: philnik, danilaml, Quuxplusone, wmaxey, arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D79555
2022-12-15 02:19:59 +01:00
|
|
|
# ifndef __has_constexpr_builtin
|
|
|
|
# define __has_constexpr_builtin(x) 0
|
|
|
|
# endif
|
|
|
|
|
2024-02-28 21:14:35 +01:00
|
|
|
// This checks wheter a Clang module is built
|
|
|
|
# ifndef __building_module
|
|
|
|
# define __building_module(...) 0
|
|
|
|
# endif
|
|
|
|
|
2015-07-10 20:26:38 +00:00
|
|
|
// '__is_identifier' returns '0' if '__x' is a reserved identifier provided by
|
|
|
|
// the compiler and '1' otherwise.
|
|
|
|
# ifndef __is_identifier
|
|
|
|
# define __is_identifier(__x) 1
|
|
|
|
# endif
|
2018-02-24 07:57:32 +00:00
|
|
|
|
2017-01-16 21:15:08 +00:00
|
|
|
# ifndef __has_declspec_attribute
|
|
|
|
# define __has_declspec_attribute(__x) 0
|
|
|
|
# endif
|
2015-07-10 20:26:38 +00:00
|
|
|
|
2023-09-07 14:48:45 -04:00
|
|
|
# define __has_keyword(__x) !(__is_identifier(__x))
|
|
|
|
|
2024-03-09 01:09:28 +01:00
|
|
|
# ifndef __has_warning
|
|
|
|
# define __has_warning(...) 0
|
|
|
|
# endif
|
|
|
|
|
2022-06-17 13:58:22 +02:00
|
|
|
# if !defined(_LIBCPP_COMPILER_CLANG_BASED) && __cplusplus < 201103L
|
|
|
|
# error "libc++ only supports C++03 with Clang-based compilers. Please enable C++11"
|
Make GCC in C++03 Unsupported
Summary:
This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists.
Below is the rational for this decision.
----------------------------------------------------------------------------------------------------
libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.
Our C++03 users are all using Clang. They must be. Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.
Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::
* Improve Correctness:
Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.
* Achieve ABI stability between C++03 and C++11
Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.
* Decrease Compile Times and Memory Usage:
Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.
* Decrease Binary Size
Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne, EricWF
Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D63154
llvm-svn: 363219
2019-06-13 00:37:25 +00:00
|
|
|
# endif
|
|
|
|
|
2019-03-05 01:57:01 +00:00
|
|
|
# if defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_NO_VCRUNTIME)
|
|
|
|
# define _LIBCPP_ABI_VCRUNTIME
|
|
|
|
# endif
|
|
|
|
|
2022-07-20 10:42:04 -04:00
|
|
|
# if __has_feature(experimental_library)
|
|
|
|
# ifndef _LIBCPP_ENABLE_EXPERIMENTAL
|
|
|
|
# define _LIBCPP_ENABLE_EXPERIMENTAL
|
|
|
|
# endif
|
|
|
|
# endif
|
|
|
|
|
2022-06-30 11:57:52 -04:00
|
|
|
// Incomplete features get their own specific disabling flags. This makes it
|
|
|
|
// easier to grep for target specific flags once the feature is complete.
|
2025-01-24 09:34:42 +01:00
|
|
|
# if defined(_LIBCPP_ENABLE_EXPERIMENTAL) || defined(_LIBCPP_BUILDING_LIBRARY)
|
|
|
|
# define _LIBCPP_HAS_EXPERIMENTAL_LIBRARY 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_EXPERIMENTAL_LIBRARY 0
|
2023-07-10 10:55:55 -04:00
|
|
|
# endif
|
|
|
|
|
2025-01-24 09:34:42 +01:00
|
|
|
# define _LIBCPP_HAS_EXPERIMENTAL_PSTL _LIBCPP_HAS_EXPERIMENTAL_LIBRARY
|
|
|
|
# define _LIBCPP_HAS_EXPERIMENTAL_TZDB _LIBCPP_HAS_EXPERIMENTAL_LIBRARY
|
|
|
|
# define _LIBCPP_HAS_EXPERIMENTAL_SYNCSTREAM _LIBCPP_HAS_EXPERIMENTAL_LIBRARY
|
|
|
|
|
2017-10-17 13:16:01 +00:00
|
|
|
# if defined(__MVS__)
|
2010-08-22 00:02:43 +00:00
|
|
|
# include <features.h> // for __NATIVE_ASCII_F
|
|
|
|
# endif
|
2010-05-11 19:42:16 +00:00
|
|
|
|
2017-10-04 23:44:38 +00:00
|
|
|
# if defined(_WIN32)
|
2017-05-31 22:14:05 +00:00
|
|
|
# define _LIBCPP_WIN32API
|
2017-10-17 13:16:01 +00:00
|
|
|
# define _LIBCPP_SHORT_WCHAR 1
|
2019-03-20 17:05:52 +00:00
|
|
|
// Both MinGW and native MSVC provide a "MSVC"-like environment
|
2017-05-31 22:14:05 +00:00
|
|
|
# define _LIBCPP_MSVCRT_LIKE
|
2017-07-17 21:52:31 +00:00
|
|
|
// If mingw not explicitly detected, assume using MS C runtime only if
|
|
|
|
// a MS compatibility version is specified.
|
|
|
|
# if defined(_MSC_VER) && !defined(__MINGW32__)
|
2013-09-17 01:34:47 +00:00
|
|
|
# define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library
|
|
|
|
# endif
|
2017-01-04 01:53:24 +00:00
|
|
|
# if (defined(_M_AMD64) || defined(__x86_64__)) || (defined(_M_ARM) || defined(__arm__))
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_BITSCAN64 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_BITSCAN64 0
|
2017-01-04 01:53:24 +00:00
|
|
|
# endif
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_OPEN_WITH_WCHAR 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_OPEN_WITH_WCHAR 0
|
|
|
|
# define _LIBCPP_HAS_BITSCAN64 0
|
2017-01-03 21:53:51 +00:00
|
|
|
# endif // defined(_WIN32)
|
2011-05-13 17:16:06 +00:00
|
|
|
|
2021-09-09 16:20:36 -04:00
|
|
|
# if defined(_AIX) && !defined(__64BIT__)
|
|
|
|
// The size of wchar is 2 byte on 32-bit mode on AIX.
|
|
|
|
# define _LIBCPP_SHORT_WCHAR 1
|
|
|
|
# endif
|
|
|
|
|
2021-12-21 16:50:34 -05:00
|
|
|
// 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.
|
|
|
|
//
|
2022-01-02 11:53:53 -08:00
|
|
|
// _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.
|
|
|
|
//
|
2021-12-21 16:50:34 -05:00
|
|
|
// _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.
|
2022-04-24 21:45:49 -04:00
|
|
|
# if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || \
|
2022-11-24 13:02:58 -05:00
|
|
|
defined(__DragonFly__)
|
2021-12-21 16:50:34 -05:00
|
|
|
# define _LIBCPP_USING_ARC4_RANDOM
|
2021-05-22 06:39:33 -07:00
|
|
|
# elif defined(__wasi__) || defined(__EMSCRIPTEN__)
|
2021-12-21 16:50:34 -05:00
|
|
|
# define _LIBCPP_USING_GETENTROPY
|
2022-01-02 11:53:53 -08:00
|
|
|
# elif defined(__Fuchsia__)
|
|
|
|
# define _LIBCPP_USING_FUCHSIA_CPRNG
|
2021-12-21 16:50:34 -05:00
|
|
|
# elif defined(__native_client__)
|
|
|
|
# define _LIBCPP_USING_NACL_RANDOM
|
|
|
|
# elif defined(_LIBCPP_WIN32API)
|
|
|
|
# define _LIBCPP_USING_WIN32_RANDOM
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_USING_DEV_RANDOM
|
2010-05-24 17:49:41 +00:00
|
|
|
# endif
|
2010-05-11 19:42:16 +00:00
|
|
|
|
2019-01-16 01:51:12 +00:00
|
|
|
# ifndef _LIBCPP_CXX03_LANG
|
2022-06-17 13:58:22 +02:00
|
|
|
|
2019-01-16 01:51:12 +00:00
|
|
|
# define _LIBCPP_ALIGNOF(_Tp) alignof(_Tp)
|
2022-06-17 13:58:22 +02:00
|
|
|
# define _ALIGNAS_TYPE(x) alignas(x)
|
|
|
|
# define _ALIGNAS(x) alignas(x)
|
|
|
|
# define _NOEXCEPT noexcept
|
2024-01-30 08:33:48 -05:00
|
|
|
# define _NOEXCEPT_(...) noexcept(__VA_ARGS__)
|
2022-08-09 13:22:25 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR constexpr
|
2022-06-17 13:58:22 +02:00
|
|
|
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# else
|
2022-06-17 13:58:22 +02:00
|
|
|
|
|
|
|
# define _LIBCPP_ALIGNOF(_Tp) _Alignof(_Tp)
|
|
|
|
# define _ALIGNAS_TYPE(x) __attribute__((__aligned__(_LIBCPP_ALIGNOF(x))))
|
|
|
|
# define _ALIGNAS(x) __attribute__((__aligned__(x)))
|
|
|
|
# define nullptr __nullptr
|
|
|
|
# define _NOEXCEPT throw()
|
2024-01-30 08:33:48 -05:00
|
|
|
# define _NOEXCEPT_(...)
|
2022-08-09 13:22:25 +02:00
|
|
|
# define static_assert(...) _Static_assert(__VA_ARGS__)
|
|
|
|
# define decltype(...) __decltype(__VA_ARGS__)
|
|
|
|
# define _LIBCPP_CONSTEXPR
|
2022-06-17 13:58:22 +02:00
|
|
|
|
|
|
|
typedef __char16_t char16_t;
|
|
|
|
typedef __char32_t char32_t;
|
|
|
|
|
|
|
|
# endif
|
|
|
|
|
2021-04-01 08:29:55 +02:00
|
|
|
# define _LIBCPP_PREFERRED_ALIGNOF(_Tp) __alignof(_Tp)
|
2010-08-10 20:48:29 +00:00
|
|
|
|
2011-06-22 22:17:44 +00:00
|
|
|
// Objective-C++ features (opt-in)
|
2024-07-13 09:41:36 +02:00
|
|
|
# if __has_feature(objc_arc)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_OBJC_ARC 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_OBJC_ARC 0
|
2024-07-13 09:41:36 +02:00
|
|
|
# endif
|
[libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITY
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.
It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:
http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.
In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html
Reviewers: EricWF, dexonsmith, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49240
llvm-svn: 338122
2018-07-27 12:46:03 +00:00
|
|
|
|
2024-07-13 09:41:36 +02:00
|
|
|
# if __has_feature(objc_arc_weak)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_OBJC_ARC_WEAK 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_OBJC_ARC_WEAK 0
|
2024-07-13 09:41:36 +02:00
|
|
|
# endif
|
2019-09-04 12:44:19 +00:00
|
|
|
|
2024-07-13 09:41:36 +02:00
|
|
|
# if __has_extension(blocks)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_EXTENSION_BLOCKS 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_EXTENSION_BLOCKS 0
|
2024-07-13 09:41:36 +02:00
|
|
|
# endif
|
2010-08-10 20:48:29 +00:00
|
|
|
|
2024-10-12 09:49:52 +02:00
|
|
|
# if _LIBCPP_HAS_EXTENSION_BLOCKS && defined(__APPLE__)
|
|
|
|
# define _LIBCPP_HAS_BLOCKS_RUNTIME 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_BLOCKS_RUNTIME 0
|
2024-07-13 09:41:36 +02:00
|
|
|
# endif
|
2014-04-14 15:44:57 +00:00
|
|
|
|
2024-10-12 09:49:52 +02:00
|
|
|
# if __has_feature(address_sanitizer)
|
|
|
|
# define _LIBCPP_HAS_ASAN 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_ASAN 0
|
2024-07-13 09:41:36 +02:00
|
|
|
# endif
|
[libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITY
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.
It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:
http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.
In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html
Reviewers: EricWF, dexonsmith, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49240
llvm-svn: 338122
2018-07-27 12:46:03 +00:00
|
|
|
|
2024-07-13 09:41:36 +02:00
|
|
|
# define _LIBCPP_ALWAYS_INLINE __attribute__((__always_inline__))
|
2019-09-04 12:44:19 +00:00
|
|
|
|
2024-07-13 09:41:36 +02:00
|
|
|
# define _LIBCPP_DISABLE_EXTENSION_WARNING __extension__
|
2010-05-11 19:42:16 +00:00
|
|
|
|
2017-01-03 21:53:51 +00:00
|
|
|
# if defined(_LIBCPP_OBJECT_FORMAT_COFF)
|
2018-02-24 07:57:32 +00:00
|
|
|
|
2018-01-17 04:37:04 +00:00
|
|
|
# ifdef _DLL
|
|
|
|
# define _LIBCPP_CRT_FUNC __declspec(dllimport)
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_CRT_FUNC
|
|
|
|
# endif
|
|
|
|
|
2022-04-10 00:32:03 +03:00
|
|
|
# if defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) || (defined(__MINGW32__) && !defined(_LIBCPP_BUILDING_LIBRARY))
|
2016-09-26 22:19:41 +00:00
|
|
|
# define _LIBCPP_DLL_VIS
|
|
|
|
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
|
|
|
|
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
|
2016-11-16 22:18:10 +00:00
|
|
|
# define _LIBCPP_OVERRIDABLE_FUNC_VIS
|
2018-10-25 12:13:43 +00:00
|
|
|
# define _LIBCPP_EXPORTED_FROM_ABI
|
2016-09-26 22:19:41 +00:00
|
|
|
# elif defined(_LIBCPP_BUILDING_LIBRARY)
|
2016-09-15 22:27:07 +00:00
|
|
|
# define _LIBCPP_DLL_VIS __declspec(dllexport)
|
2019-04-25 19:46:28 +00:00
|
|
|
# if defined(__MINGW32__)
|
|
|
|
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
|
|
|
|
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS
|
|
|
|
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS _LIBCPP_DLL_VIS
|
|
|
|
# endif
|
2016-11-16 22:18:10 +00:00
|
|
|
# define _LIBCPP_OVERRIDABLE_FUNC_VIS _LIBCPP_DLL_VIS
|
2018-10-25 12:13:43 +00:00
|
|
|
# define _LIBCPP_EXPORTED_FROM_ABI __declspec(dllexport)
|
2016-09-26 22:19:41 +00:00
|
|
|
# else
|
2016-09-15 22:27:07 +00:00
|
|
|
# define _LIBCPP_DLL_VIS __declspec(dllimport)
|
2016-09-19 18:29:07 +00:00
|
|
|
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_DLL_VIS
|
|
|
|
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
|
2016-11-16 22:18:10 +00:00
|
|
|
# define _LIBCPP_OVERRIDABLE_FUNC_VIS
|
2018-10-25 12:13:43 +00:00
|
|
|
# define _LIBCPP_EXPORTED_FROM_ABI __declspec(dllimport)
|
2016-09-15 22:27:07 +00:00
|
|
|
# endif
|
2016-09-26 22:19:41 +00:00
|
|
|
|
2016-09-15 22:27:07 +00:00
|
|
|
# define _LIBCPP_HIDDEN
|
[libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export members
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
2017-03-02 03:02:50 +00:00
|
|
|
# define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
|
2017-01-04 23:56:00 +00:00
|
|
|
# define _LIBCPP_TEMPLATE_VIS
|
2021-02-22 01:13:13 +02:00
|
|
|
# define _LIBCPP_TEMPLATE_DATA_VIS
|
2023-08-19 15:15:47 -07:00
|
|
|
# define _LIBCPP_TYPE_VISIBILITY_DEFAULT
|
2017-01-03 21:53:51 +00:00
|
|
|
|
2022-06-22 11:14:04 +02:00
|
|
|
# else
|
2016-09-15 22:27:07 +00:00
|
|
|
|
2016-12-05 19:40:12 +00:00
|
|
|
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
|
2022-06-22 11:14:04 +02:00
|
|
|
# define _LIBCPP_VISIBILITY(vis) __attribute__((__visibility__(vis)))
|
2016-12-05 19:40:12 +00:00
|
|
|
# else
|
2022-06-22 11:14:04 +02:00
|
|
|
# define _LIBCPP_VISIBILITY(vis)
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
2016-09-15 22:27:07 +00:00
|
|
|
|
2022-06-22 11:14:04 +02:00
|
|
|
# define _LIBCPP_HIDDEN _LIBCPP_VISIBILITY("hidden")
|
|
|
|
# define _LIBCPP_TEMPLATE_DATA_VIS _LIBCPP_VISIBILITY("default")
|
|
|
|
# define _LIBCPP_EXPORTED_FROM_ABI _LIBCPP_VISIBILITY("default")
|
|
|
|
# define _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS _LIBCPP_VISIBILITY("default")
|
|
|
|
# define _LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS
|
2024-11-26 18:45:03 -05:00
|
|
|
|
|
|
|
// TODO: Make this a proper customization point or remove the option to override it.
|
|
|
|
# ifndef _LIBCPP_OVERRIDABLE_FUNC_VIS
|
|
|
|
# define _LIBCPP_OVERRIDABLE_FUNC_VIS _LIBCPP_VISIBILITY("default")
|
|
|
|
# endif
|
2022-07-14 15:04:36 +02:00
|
|
|
|
2017-03-09 00:18:00 +00:00
|
|
|
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
|
[libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export members
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
2017-03-02 03:02:50 +00:00
|
|
|
// The inline should be removed once PR32114 is resolved
|
|
|
|
# define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS inline _LIBCPP_HIDDEN
|
2017-03-09 00:18:00 +00:00
|
|
|
# else
|
|
|
|
# define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
2016-09-15 22:27:07 +00:00
|
|
|
|
2023-08-19 15:15:47 -07:00
|
|
|
// GCC doesn't support the type_visibility attribute, so we have to keep the visibility attribute on templates
|
|
|
|
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && !__has_attribute(__type_visibility__)
|
|
|
|
# define _LIBCPP_TEMPLATE_VIS __attribute__((__visibility__("default")))
|
2017-03-02 03:22:18 +00:00
|
|
|
# else
|
|
|
|
# define _LIBCPP_TEMPLATE_VIS
|
|
|
|
# endif
|
2016-09-15 22:27:07 +00:00
|
|
|
|
2021-01-12 10:29:03 -08:00
|
|
|
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
|
2023-08-19 15:15:47 -07:00
|
|
|
# define _LIBCPP_TYPE_VISIBILITY_DEFAULT __attribute__((__type_visibility__("default")))
|
2016-09-15 22:27:07 +00:00
|
|
|
# else
|
2023-08-19 15:15:47 -07:00
|
|
|
# define _LIBCPP_TYPE_VISIBILITY_DEFAULT
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
2016-09-19 18:29:07 +00:00
|
|
|
|
2022-06-22 11:14:04 +02:00
|
|
|
# endif // defined(_LIBCPP_OBJECT_FORMAT_COFF)
|
2018-10-29 17:30:04 +00:00
|
|
|
|
2023-05-24 08:46:13 -07:00
|
|
|
# if __has_attribute(exclude_from_explicit_instantiation)
|
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
2018-08-16 12:44:28 +00:00
|
|
|
# define _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((__exclude_from_explicit_instantiation__))
|
|
|
|
# else
|
2018-10-29 17:30:04 +00:00
|
|
|
// 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.
|
|
|
|
# define _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION _LIBCPP_ALWAYS_INLINE
|
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
2018-08-16 12:44:28 +00:00
|
|
|
# endif
|
[libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITY
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.
It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:
http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.
In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html
Reviewers: EricWF, dexonsmith, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49240
llvm-svn: 338122
2018-07-27 12:46:03 +00:00
|
|
|
|
2024-03-09 01:09:28 +01:00
|
|
|
# ifdef _LIBCPP_COMPILER_CLANG_BASED
|
|
|
|
# define _LIBCPP_DIAGNOSTIC_PUSH _Pragma("clang diagnostic push")
|
|
|
|
# define _LIBCPP_DIAGNOSTIC_POP _Pragma("clang diagnostic pop")
|
|
|
|
# define _LIBCPP_CLANG_DIAGNOSTIC_IGNORED(str) _Pragma(_LIBCPP_TOSTRING(clang diagnostic ignored str))
|
|
|
|
# define _LIBCPP_GCC_DIAGNOSTIC_IGNORED(str)
|
|
|
|
# elif defined(_LIBCPP_COMPILER_GCC)
|
|
|
|
# define _LIBCPP_DIAGNOSTIC_PUSH _Pragma("GCC diagnostic push")
|
|
|
|
# define _LIBCPP_DIAGNOSTIC_POP _Pragma("GCC diagnostic pop")
|
|
|
|
# define _LIBCPP_CLANG_DIAGNOSTIC_IGNORED(str)
|
|
|
|
# define _LIBCPP_GCC_DIAGNOSTIC_IGNORED(str) _Pragma(_LIBCPP_TOSTRING(GCC diagnostic ignored str))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DIAGNOSTIC_PUSH
|
|
|
|
# define _LIBCPP_DIAGNOSTIC_POP
|
|
|
|
# define _LIBCPP_CLANG_DIAGNOSTIC_IGNORED(str)
|
|
|
|
# define _LIBCPP_GCC_DIAGNOSTIC_IGNORED(str)
|
|
|
|
# endif
|
|
|
|
|
2023-11-08 09:10:00 -10:00
|
|
|
# if _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_FAST
|
|
|
|
# define _LIBCPP_HARDENING_SIG f
|
|
|
|
# elif _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_EXTENSIVE
|
2023-10-26 09:05:16 -04:00
|
|
|
# define _LIBCPP_HARDENING_SIG s
|
2023-11-08 09:10:00 -10:00
|
|
|
# elif _LIBCPP_HARDENING_MODE == _LIBCPP_HARDENING_MODE_DEBUG
|
2023-10-26 09:05:16 -04:00
|
|
|
# define _LIBCPP_HARDENING_SIG d
|
|
|
|
# else
|
2023-11-08 09:10:00 -10:00
|
|
|
# define _LIBCPP_HARDENING_SIG n // "none"
|
2023-10-26 09:05:16 -04:00
|
|
|
# endif
|
|
|
|
|
2024-10-12 09:49:52 +02:00
|
|
|
# if !_LIBCPP_HAS_EXCEPTIONS
|
2023-10-26 09:05:16 -04:00
|
|
|
# define _LIBCPP_EXCEPTIONS_SIG n
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_EXCEPTIONS_SIG e
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# define _LIBCPP_ODR_SIGNATURE \
|
|
|
|
_LIBCPP_CONCAT(_LIBCPP_CONCAT(_LIBCPP_HARDENING_SIG, _LIBCPP_EXCEPTIONS_SIG), _LIBCPP_VERSION)
|
|
|
|
|
2022-07-07 14:07:37 -04:00
|
|
|
// 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.
|
|
|
|
//
|
2023-10-26 09:05:16 -04:00
|
|
|
// 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.
|
2022-07-07 14:07:37 -04:00
|
|
|
//
|
2023-05-24 08:46:13 -07:00
|
|
|
// 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.
|
|
|
|
//
|
2022-12-21 10:08:54 -05:00
|
|
|
// 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.
|
|
|
|
//
|
2024-03-25 18:33:30 +01:00
|
|
|
// 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.
|
|
|
|
//
|
2022-07-07 14:07:37 -04:00
|
|
|
// 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.
|
|
|
|
# ifndef _LIBCPP_NO_ABI_TAG
|
|
|
|
# define _LIBCPP_HIDE_FROM_ABI \
|
2023-05-24 08:46:13 -07:00
|
|
|
_LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION \
|
2023-10-26 09:05:16 -04:00
|
|
|
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_ODR_SIGNATURE))))
|
2022-07-07 14:07:37 -04:00
|
|
|
# else
|
2023-05-24 08:46:13 -07:00
|
|
|
# define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
2023-05-24 08:46:13 -07:00
|
|
|
# define _LIBCPP_HIDE_FROM_ABI_VIRTUAL _LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION
|
2023-01-25 07:34:55 +00:00
|
|
|
|
2018-08-06 14:11:50 +00:00
|
|
|
# ifdef _LIBCPP_BUILDING_LIBRARY
|
|
|
|
# if _LIBCPP_ABI_VERSION > 1
|
2023-05-24 08:46:13 -07:00
|
|
|
# define _LIBCPP_HIDE_FROM_ABI_AFTER_V1 _LIBCPP_HIDE_FROM_ABI
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# else
|
2018-08-06 14:11:50 +00:00
|
|
|
# define _LIBCPP_HIDE_FROM_ABI_AFTER_V1
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
2016-12-05 19:40:12 +00:00
|
|
|
# else
|
2023-05-24 08:46:13 -07:00
|
|
|
# define _LIBCPP_HIDE_FROM_ABI_AFTER_V1 _LIBCPP_HIDE_FROM_ABI
|
2016-12-05 19:40:12 +00:00
|
|
|
# endif
|
[libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI compatibility
Summary:
GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'.
```
// RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
// RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
#define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline))
template <class T>
struct Foo {
void foo();
void bar();
};
template <class T>
void Foo<T>::foo() {}
template <class T>
inline INLINE_VISIBILITY
void Foo<T>::bar() {}
template struct Foo<int>;
```
This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated).
Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline` therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors).
This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`.
After applying this patch GCC dylibs now contain:
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE`
* `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl`
* `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw`
This patch has no effect on Clang based builds.
Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF
Subscribers: beanz, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24600
llvm-svn: 281681
2016-09-16 00:00:48 +00:00
|
|
|
|
2024-03-09 01:09:28 +01:00
|
|
|
// TODO: Remove this workaround once we drop support for Clang 16
|
|
|
|
# if __has_warning("-Wc++23-extensions")
|
|
|
|
# define _LIBCPP_CLANG_DIAGNOSTIC_IGNORED_CXX23_EXTENSION _LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wc++23-extensions")
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_CLANG_DIAGNOSTIC_IGNORED_CXX23_EXTENSION _LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wc++2b-extensions")
|
|
|
|
# endif
|
|
|
|
|
2024-03-23 13:54:35 +01:00
|
|
|
// Clang modules take a significant compile time hit when pushing and popping diagnostics.
|
|
|
|
// Since all the headers are marked as system headers in the modulemap, we can simply disable this
|
|
|
|
// pushing and popping when building with clang modules.
|
|
|
|
# if !__has_feature(modules)
|
|
|
|
# define _LIBCPP_PUSH_EXTENSION_DIAGNOSTICS \
|
|
|
|
_LIBCPP_DIAGNOSTIC_PUSH \
|
|
|
|
_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wc++11-extensions") \
|
|
|
|
_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wc++14-extensions") \
|
|
|
|
_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wc++17-extensions") \
|
|
|
|
_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Wc++20-extensions") \
|
|
|
|
_LIBCPP_CLANG_DIAGNOSTIC_IGNORED_CXX23_EXTENSION \
|
|
|
|
_LIBCPP_GCC_DIAGNOSTIC_IGNORED("-Wc++14-extensions") \
|
|
|
|
_LIBCPP_GCC_DIAGNOSTIC_IGNORED("-Wc++17-extensions") \
|
|
|
|
_LIBCPP_GCC_DIAGNOSTIC_IGNORED("-Wc++20-extensions") \
|
|
|
|
_LIBCPP_GCC_DIAGNOSTIC_IGNORED("-Wc++23-extensions")
|
|
|
|
# define _LIBCPP_POP_EXTENSION_DIAGNOSTICS _LIBCPP_DIAGNOSTIC_POP
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_PUSH_EXTENSION_DIAGNOSTICS
|
|
|
|
# define _LIBCPP_POP_EXTENSION_DIAGNOSTICS
|
|
|
|
# endif
|
|
|
|
|
2018-10-30 02:02:00 +00:00
|
|
|
// Inline namespaces are available in Clang/GCC/MSVC regardless of C++ dialect.
|
2018-10-29 17:30:04 +00:00
|
|
|
// clang-format off
|
2024-03-23 13:54:35 +01:00
|
|
|
# define _LIBCPP_BEGIN_NAMESPACE_STD _LIBCPP_PUSH_EXTENSION_DIAGNOSTICS \
|
2024-03-09 01:09:28 +01:00
|
|
|
namespace _LIBCPP_TYPE_VISIBILITY_DEFAULT std { \
|
2023-08-19 15:15:47 -07:00
|
|
|
inline namespace _LIBCPP_ABI_NAMESPACE {
|
2024-03-23 13:54:35 +01:00
|
|
|
# define _LIBCPP_END_NAMESPACE_STD }} _LIBCPP_POP_EXTENSION_DIAGNOSTICS
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
|
2024-09-11 14:59:43 -04:00
|
|
|
#define _LIBCPP_BEGIN_NAMESPACE_EXPERIMENTAL namespace std { namespace experimental {
|
|
|
|
#define _LIBCPP_END_NAMESPACE_EXPERIMENTAL }}
|
|
|
|
|
|
|
|
#define _LIBCPP_BEGIN_NAMESPACE_LFTS _LIBCPP_BEGIN_NAMESPACE_EXPERIMENTAL inline namespace fundamentals_v1 {
|
|
|
|
#define _LIBCPP_END_NAMESPACE_LFTS } _LIBCPP_END_NAMESPACE_EXPERIMENTAL
|
|
|
|
|
|
|
|
#define _LIBCPP_BEGIN_NAMESPACE_LFTS_V2 _LIBCPP_BEGIN_NAMESPACE_EXPERIMENTAL inline namespace fundamentals_v2 {
|
|
|
|
#define _LIBCPP_END_NAMESPACE_LFTS_V2 } _LIBCPP_END_NAMESPACE_EXPERIMENTAL
|
|
|
|
|
2024-06-01 08:37:49 +02:00
|
|
|
#ifdef _LIBCPP_ABI_NO_FILESYSTEM_INLINE_NAMESPACE
|
|
|
|
# define _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM _LIBCPP_BEGIN_NAMESPACE_STD namespace filesystem {
|
|
|
|
# define _LIBCPP_END_NAMESPACE_FILESYSTEM } _LIBCPP_END_NAMESPACE_STD
|
|
|
|
#else
|
2023-11-28 18:41:59 -05:00
|
|
|
# define _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM _LIBCPP_BEGIN_NAMESPACE_STD \
|
|
|
|
inline namespace __fs { namespace filesystem {
|
2018-10-30 02:02:00 +00:00
|
|
|
|
2024-03-09 01:09:28 +01:00
|
|
|
# define _LIBCPP_END_NAMESPACE_FILESYSTEM }} _LIBCPP_END_NAMESPACE_STD
|
2024-06-01 08:37:49 +02:00
|
|
|
#endif
|
|
|
|
|
2019-07-25 20:29:20 +00:00
|
|
|
// clang-format on
|
2018-10-30 02:02:00 +00:00
|
|
|
|
2021-06-04 13:31:22 -04:00
|
|
|
# if __has_attribute(__enable_if__)
|
|
|
|
# define _LIBCPP_PREFERRED_OVERLOAD __attribute__((__enable_if__(true, "")))
|
2016-09-15 22:27:07 +00:00
|
|
|
# endif
|
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# if !defined(__SIZEOF_INT128__) || defined(_MSC_VER)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_INT128 0
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_INT128 1
|
2014-03-26 19:45:52 +00:00
|
|
|
# endif
|
|
|
|
|
2022-02-11 19:34:33 +01:00
|
|
|
# ifdef _LIBCPP_CXX03_LANG
|
2013-03-06 23:30:19 +00:00
|
|
|
# define _LIBCPP_DECLARE_STRONG_ENUM(x) \
|
2023-06-16 14:32:08 -04:00
|
|
|
struct _LIBCPP_EXPORTED_FROM_ABI x { \
|
2013-03-06 23:30:19 +00:00
|
|
|
enum __lx
|
2018-10-29 17:30:04 +00:00
|
|
|
// clang-format off
|
2011-12-02 19:36:40 +00:00
|
|
|
# define _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(x) \
|
2012-10-30 19:06:59 +00:00
|
|
|
__lx __v_; \
|
2018-07-11 23:14:33 +00:00
|
|
|
_LIBCPP_HIDE_FROM_ABI x(__lx __v) : __v_(__v) {} \
|
|
|
|
_LIBCPP_HIDE_FROM_ABI explicit x(int __v) : __v_(static_cast<__lx>(__v)) {} \
|
|
|
|
_LIBCPP_HIDE_FROM_ABI operator int() const { return __v_; } \
|
2011-12-02 19:36:40 +00:00
|
|
|
};
|
2019-07-25 20:29:20 +00:00
|
|
|
// clang-format on
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
|
2022-02-11 19:34:33 +01:00
|
|
|
# else // _LIBCPP_CXX03_LANG
|
2023-08-19 15:15:47 -07:00
|
|
|
# define _LIBCPP_DECLARE_STRONG_ENUM(x) enum class x
|
2011-12-02 19:36:40 +00:00
|
|
|
# define _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(x)
|
2022-02-11 19:34:33 +01:00
|
|
|
# endif // _LIBCPP_CXX03_LANG
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
|
2013-03-18 19:34:07 +00:00
|
|
|
# ifdef __FreeBSD__
|
2011-11-13 17:15:33 +00:00
|
|
|
# define _DECLARE_C99_LDBL_MATH 1
|
|
|
|
# endif
|
2011-07-15 05:40:33 +00:00
|
|
|
|
2018-04-19 22:12:10 +00:00
|
|
|
// 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.
|
|
|
|
# if defined(_LIBCPP_MSVCRT) && defined(_MSC_VER) && _MSC_VER < 1912
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_LIBRARY_ALIGNED_ALLOCATION 0
|
2019-03-05 01:57:01 +00:00
|
|
|
# elif defined(_LIBCPP_ABI_VCRUNTIME) && !defined(__cpp_aligned_new)
|
2019-03-20 17:05:52 +00:00
|
|
|
// We're deferring to Microsoft's STL to provide aligned new et al. We don't
|
[libc++] Don't define operator new/delete when using vcruntime
Fixes build errors on Windows without libc++abi of the form:
new(173,36): error: redeclaration of 'operator delete' cannot add 'dllexport' attribute
_LIBCPP_OVERRIDABLE_FUNC_VIS void operator delete(void* __p) _NOEXCEPT;
vcruntime_new.h(87,16): note: previous declaration is here
void __CRTDECL operator delete(
new(205,70): error: redefinition of 'operator new'
_LIBCPP_NODISCARD_AFTER_CXX17 inline _LIBCPP_INLINE_VISIBILITY void* operator new (std::size_t, void* __p) _NOEXCEPT {return __p;}
vcruntime_new.h(184,28): note: previous definition is here
inline void* __CRTDECL operator new(size_t _Size, _Writable_bytes_(_Size) void* _Where) noexcept
new(206,70): error: redefinition of 'operator new[]'
_LIBCPP_NODISCARD_AFTER_CXX17 inline _LIBCPP_INLINE_VISIBILITY void* operator new[](std::size_t, void* __p) _NOEXCEPT {return __p;}
vcruntime_new.h(199,28): note: previous definition is here
inline void* __CRTDECL operator new[](size_t _Size,
new(207,40): error: redefinition of 'operator delete'
inline _LIBCPP_INLINE_VISIBILITY void operator delete (void*, void*) _NOEXCEPT {}
vcruntime_new.h(190,27): note: previous definition is here
inline void __CRTDECL operator delete(void*, void*) noexcept
new(208,40): error: redefinition of 'operator delete[]'
inline _LIBCPP_INLINE_VISIBILITY void operator delete[](void*, void*) _NOEXCEPT {}
vcruntime_new.h(206,27): note: previous definition is here
inline void __CRTDECL operator delete[](void*, void*) noexcept
Differential Revision: https://reviews.llvm.org/D57362
llvm-svn: 352647
2019-01-30 19:08:32 +00:00
|
|
|
// have it unless the language feature test macro is defined.
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_LIBRARY_ALIGNED_ALLOCATION 0
|
2020-11-12 14:40:35 -05:00
|
|
|
# elif defined(__MVS__)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_LIBRARY_ALIGNED_ALLOCATION 0
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_LIBRARY_ALIGNED_ALLOCATION 1
|
2018-04-19 22:12:10 +00:00
|
|
|
# endif
|
|
|
|
|
2024-10-12 09:49:52 +02:00
|
|
|
# if !_LIBCPP_HAS_LIBRARY_ALIGNED_ALLOCATION || (!defined(__cpp_aligned_new) || __cpp_aligned_new < 201606)
|
|
|
|
# define _LIBCPP_HAS_ALIGNED_ALLOCATION 0
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_ALIGNED_ALLOCATION 1
|
2018-08-10 13:24:56 +00:00
|
|
|
# endif
|
2018-03-22 04:42:56 +00:00
|
|
|
|
2022-11-17 10:19:28 +00:00
|
|
|
// 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().
|
|
|
|
# if defined(__APPLE__)
|
|
|
|
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && \
|
2024-10-12 09:49:52 +02:00
|
|
|
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101500) || \
|
|
|
|
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && \
|
2024-09-27 16:11:47 -04:00
|
|
|
__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 130000)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_C11_ALIGNED_ALLOC 0
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_C11_ALIGNED_ALLOC 1
|
2024-09-27 16:11:47 -04:00
|
|
|
# endif
|
2023-01-06 23:35:15 -08:00
|
|
|
# elif defined(__ANDROID__) && __ANDROID_API__ < 28
|
|
|
|
// Android only provides aligned_alloc when targeting API 28 or higher.
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_C11_ALIGNED_ALLOC 0
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_C11_ALIGNED_ALLOC 1
|
2022-11-17 10:19:28 +00:00
|
|
|
# endif
|
|
|
|
|
2013-03-18 19:34:07 +00:00
|
|
|
# if defined(__APPLE__) || defined(__FreeBSD__)
|
2011-09-28 23:39:33 +00:00
|
|
|
# define _LIBCPP_HAS_DEFAULTRUNELOCALE
|
2011-07-09 01:09:31 +00:00
|
|
|
# endif
|
|
|
|
|
2022-11-24 13:02:58 -05:00
|
|
|
# if defined(__APPLE__) || defined(__FreeBSD__)
|
2011-07-09 03:40:04 +00:00
|
|
|
# define _LIBCPP_WCTYPE_IS_MASK
|
|
|
|
# endif
|
|
|
|
|
2018-12-11 04:35:44 +00:00
|
|
|
# if _LIBCPP_STD_VER <= 17 || !defined(__cpp_char8_t)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_CHAR8_T 0
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_CHAR8_T 1
|
2018-12-11 04:35:44 +00:00
|
|
|
# endif
|
|
|
|
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
// Deprecation macros.
|
2019-03-12 20:10:06 +00:00
|
|
|
//
|
|
|
|
// Deprecations warnings are always enabled, except when users explicitly opt-out
|
|
|
|
// by defining _LIBCPP_DISABLE_DEPRECATION_WARNINGS.
|
|
|
|
# if !defined(_LIBCPP_DISABLE_DEPRECATION_WARNINGS)
|
2023-01-10 01:56:53 +01:00
|
|
|
# if __has_attribute(__deprecated__)
|
|
|
|
# define _LIBCPP_DEPRECATED __attribute__((__deprecated__))
|
|
|
|
# define _LIBCPP_DEPRECATED_(m) __attribute__((__deprecated__(m)))
|
2023-02-14 00:56:09 +01:00
|
|
|
# elif _LIBCPP_STD_VER >= 14
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# define _LIBCPP_DEPRECATED [[deprecated]]
|
2022-06-17 16:02:53 +02:00
|
|
|
# define _LIBCPP_DEPRECATED_(m) [[deprecated(m)]]
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# else
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# define _LIBCPP_DEPRECATED
|
2022-06-17 16:02:53 +02:00
|
|
|
# define _LIBCPP_DEPRECATED_(m)
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED
|
2022-06-17 16:02:53 +02:00
|
|
|
# define _LIBCPP_DEPRECATED_(m)
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# endif
|
2013-09-28 18:35:31 +00:00
|
|
|
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# if !defined(_LIBCPP_CXX03_LANG)
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX11 _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX11
|
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 14
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX14 _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX14
|
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 17
|
[libc++] Add deprecated attributes to many deprecated components
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
2018-09-23 18:35:00 +00:00
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX17
|
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 20
|
2020-11-26 10:07:16 +01:00
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX20 _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX20
|
|
|
|
# endif
|
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# if _LIBCPP_STD_VER >= 23
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX23 _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX23
|
|
|
|
# endif
|
2022-12-11 02:10:31 +01:00
|
|
|
|
2024-01-29 20:57:12 +02:00
|
|
|
# if _LIBCPP_STD_VER >= 26
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX26 _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_IN_CXX26
|
|
|
|
# endif
|
|
|
|
|
2024-10-12 09:49:52 +02:00
|
|
|
# if _LIBCPP_HAS_CHAR8_T
|
2020-10-26 13:18:46 +02:00
|
|
|
# define _LIBCPP_DEPRECATED_WITH_CHAR8_T _LIBCPP_DEPRECATED
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DEPRECATED_WITH_CHAR8_T
|
|
|
|
# endif
|
|
|
|
|
2019-10-19 00:06:00 +00:00
|
|
|
// Macros to enter and leave a state where deprecation warnings are suppressed.
|
2021-06-04 13:31:22 -04:00
|
|
|
# if defined(_LIBCPP_COMPILER_CLANG_BASED) || defined(_LIBCPP_COMPILER_GCC)
|
|
|
|
# define _LIBCPP_SUPPRESS_DEPRECATED_PUSH \
|
2021-07-27 17:30:47 -04:00
|
|
|
_Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored \"-Wdeprecated\"") \
|
|
|
|
_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
|
2021-06-04 13:31:22 -04:00
|
|
|
# define _LIBCPP_SUPPRESS_DEPRECATED_POP _Pragma("GCC diagnostic pop")
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_SUPPRESS_DEPRECATED_PUSH
|
|
|
|
# define _LIBCPP_SUPPRESS_DEPRECATED_POP
|
2019-10-19 00:06:00 +00:00
|
|
|
# endif
|
|
|
|
|
2013-07-15 14:57:19 +00:00
|
|
|
# if _LIBCPP_STD_VER <= 11
|
2023-02-02 12:12:28 +01:00
|
|
|
# define _LIBCPP_EXPLICIT_SINCE_CXX14
|
2013-07-15 14:57:19 +00:00
|
|
|
# else
|
2023-02-02 12:12:28 +01:00
|
|
|
# define _LIBCPP_EXPLICIT_SINCE_CXX14 explicit
|
2013-07-15 14:57:19 +00:00
|
|
|
# endif
|
|
|
|
|
2023-03-22 23:24:22 +02:00
|
|
|
# if _LIBCPP_STD_VER >= 23
|
|
|
|
# define _LIBCPP_EXPLICIT_SINCE_CXX23 explicit
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_EXPLICIT_SINCE_CXX23
|
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 14
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX14 constexpr
|
2014-07-17 05:16:18 +00:00
|
|
|
# else
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX14
|
2014-07-17 05:16:18 +00:00
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 17
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX17 constexpr
|
2016-03-17 03:30:56 +00:00
|
|
|
# else
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX17
|
2016-03-17 03:30:56 +00:00
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 20
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX20 constexpr
|
2017-11-14 22:26:50 +00:00
|
|
|
# else
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX20
|
2017-11-14 22:26:50 +00:00
|
|
|
# endif
|
|
|
|
|
2023-02-14 00:56:09 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 23
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX23 constexpr
|
2022-08-13 13:52:35 +02:00
|
|
|
# else
|
2022-08-19 13:08:01 +02:00
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX23
|
2022-08-13 13:52:35 +02:00
|
|
|
# endif
|
|
|
|
|
2024-08-28 21:35:57 +08:00
|
|
|
# if _LIBCPP_STD_VER >= 26
|
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX26 constexpr
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_CONSTEXPR_SINCE_CXX26
|
|
|
|
# endif
|
|
|
|
|
2013-10-04 23:56:37 +00:00
|
|
|
# ifndef _LIBCPP_WEAK
|
|
|
|
# define _LIBCPP_WEAK __attribute__((__weak__))
|
|
|
|
# endif
|
|
|
|
|
2016-05-06 14:06:29 +00:00
|
|
|
// Thread API
|
2019-07-25 20:29:20 +00:00
|
|
|
// clang-format off
|
2024-11-06 10:39:19 +01:00
|
|
|
# if _LIBCPP_HAS_THREADS && \
|
|
|
|
!_LIBCPP_HAS_THREAD_API_PTHREAD && \
|
|
|
|
!_LIBCPP_HAS_THREAD_API_WIN32 && \
|
|
|
|
!_LIBCPP_HAS_THREAD_API_EXTERNAL
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
|
2016-05-06 14:06:29 +00:00
|
|
|
# if defined(__FreeBSD__) || \
|
2019-05-01 16:47:30 +00:00
|
|
|
defined(__wasi__) || \
|
2016-05-06 14:06:29 +00:00
|
|
|
defined(__NetBSD__) || \
|
2021-01-12 14:16:15 -05:00
|
|
|
defined(__OpenBSD__) || \
|
2020-11-18 16:16:18 -05:00
|
|
|
defined(__NuttX__) || \
|
2016-05-06 14:06:29 +00:00
|
|
|
defined(__linux__) || \
|
2018-11-20 21:14:05 +00:00
|
|
|
defined(__GNU__) || \
|
2016-05-06 14:06:29 +00:00
|
|
|
defined(__APPLE__) || \
|
2020-12-05 00:13:23 +00:00
|
|
|
defined(__MVS__) || \
|
2021-05-22 06:39:33 -07:00
|
|
|
defined(_AIX) || \
|
|
|
|
defined(__EMSCRIPTEN__)
|
2019-07-25 20:29:20 +00:00
|
|
|
// clang-format on
|
2024-11-06 10:39:19 +01:00
|
|
|
# undef _LIBCPP_HAS_THREAD_API_PTHREAD
|
|
|
|
# define _LIBCPP_HAS_THREAD_API_PTHREAD 1
|
2019-12-04 10:38:22 -08:00
|
|
|
# elif defined(__Fuchsia__)
|
2020-01-16 12:12:38 -08:00
|
|
|
// TODO(44575): Switch to C11 thread API when possible.
|
2024-11-06 10:39:19 +01:00
|
|
|
# undef _LIBCPP_HAS_THREAD_API_PTHREAD
|
|
|
|
# define _LIBCPP_HAS_THREAD_API_PTHREAD 1
|
2017-01-07 03:07:45 +00:00
|
|
|
# elif defined(_LIBCPP_WIN32API)
|
2024-11-06 10:39:19 +01:00
|
|
|
# undef _LIBCPP_HAS_THREAD_API_WIN32
|
|
|
|
# define _LIBCPP_HAS_THREAD_API_WIN32 1
|
2016-05-06 14:06:29 +00:00
|
|
|
# else
|
|
|
|
# error "No thread API"
|
2016-05-25 17:40:09 +00:00
|
|
|
# endif // _LIBCPP_HAS_THREAD_API
|
2024-11-06 10:39:19 +01:00
|
|
|
# endif // _LIBCPP_HAS_THREADS
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
|
2024-11-06 10:39:19 +01:00
|
|
|
# if _LIBCPP_HAS_THREAD_API_PTHREAD
|
2019-09-18 18:13:32 +00:00
|
|
|
# if defined(__ANDROID__) && __ANDROID_API__ >= 30
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_COND_CLOCKWAIT 1
|
2019-09-18 18:13:32 +00:00
|
|
|
# elif defined(_LIBCPP_GLIBC_PREREQ)
|
|
|
|
# if _LIBCPP_GLIBC_PREREQ(2, 30)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_COND_CLOCKWAIT 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_COND_CLOCKWAIT 0
|
2019-09-18 18:13:32 +00:00
|
|
|
# endif
|
2024-10-12 09:49:52 +02:00
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_COND_CLOCKWAIT 0
|
2019-09-18 18:13:32 +00:00
|
|
|
# endif
|
2024-10-12 09:49:52 +02:00
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_COND_CLOCKWAIT 0
|
2019-09-18 18:13:32 +00:00
|
|
|
# endif
|
|
|
|
|
2024-11-06 10:39:19 +01:00
|
|
|
# if !_LIBCPP_HAS_THREADS && _LIBCPP_HAS_THREAD_API_PTHREAD
|
|
|
|
# error _LIBCPP_HAS_THREAD_API_PTHREAD may only be true when _LIBCPP_HAS_THREADS is true.
|
2016-05-25 17:40:09 +00:00
|
|
|
# endif
|
2016-05-06 14:06:29 +00:00
|
|
|
|
2024-11-06 10:39:19 +01:00
|
|
|
# if !_LIBCPP_HAS_THREADS && _LIBCPP_HAS_THREAD_API_EXTERNAL
|
2024-11-11 13:58:34 -08:00
|
|
|
# error _LIBCPP_HAS_THREAD_API_EXTERNAL may only be true when _LIBCPP_HAS_THREADS is true.
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-11 21:46:40 +00:00
|
|
|
# endif
|
|
|
|
|
2024-11-06 10:39:19 +01:00
|
|
|
# if !_LIBCPP_HAS_MONOTONIC_CLOCK && _LIBCPP_HAS_THREADS
|
|
|
|
# error _LIBCPP_HAS_MONOTONIC_CLOCK may only be false when _LIBCPP_HAS_THREADS is false.
|
2014-12-06 20:09:11 +00:00
|
|
|
# endif
|
|
|
|
|
2024-11-06 10:39:19 +01:00
|
|
|
# if _LIBCPP_HAS_THREADS && !defined(__STDCPP_THREADS__)
|
2019-07-30 14:32:47 +00:00
|
|
|
# define __STDCPP_THREADS__ 1
|
|
|
|
# endif
|
|
|
|
|
2019-07-25 20:29:20 +00:00
|
|
|
// The glibc and Bionic implementation of pthreads implements
|
2019-07-07 17:24:03 +00:00
|
|
|
// pthread_mutex_destroy as nop for regular mutexes. Additionally, Win32
|
|
|
|
// mutexes have no destroy mechanism.
|
2019-07-25 20:29:20 +00:00
|
|
|
//
|
|
|
|
// 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
|
2024-11-06 10:39:19 +01:00
|
|
|
# if (_LIBCPP_HAS_THREAD_API_PTHREAD && defined(__GLIBC__)) || \
|
|
|
|
(_LIBCPP_HAS_THREAD_API_C11 && defined(__Fuchsia__)) || \
|
|
|
|
_LIBCPP_HAS_THREAD_API_WIN32
|
2019-07-25 20:29:20 +00:00
|
|
|
// clang-format on
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_TRIVIAL_MUTEX_DESTRUCTION 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_TRIVIAL_MUTEX_DESTRUCTION 0
|
2019-07-07 01:20:54 +00:00
|
|
|
# endif
|
|
|
|
|
2019-07-07 17:24:03 +00:00
|
|
|
// Destroying a condvar is a nop on Windows.
|
2019-07-25 20:29:20 +00:00
|
|
|
//
|
|
|
|
// 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.
|
|
|
|
//
|
2019-07-07 17:24:03 +00:00
|
|
|
// TODO(EricWF): This is potentially true for some pthread implementations
|
|
|
|
// as well.
|
2024-11-06 10:39:19 +01:00
|
|
|
# if (_LIBCPP_HAS_THREAD_API_C11 && defined(__Fuchsia__)) || _LIBCPP_HAS_THREAD_API_WIN32
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_TRIVIAL_CONDVAR_DESTRUCTION 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_TRIVIAL_CONDVAR_DESTRUCTION 0
|
2019-07-07 17:24:03 +00:00
|
|
|
# endif
|
|
|
|
|
2017-01-14 04:27:58 +00:00
|
|
|
# if defined(__BIONIC__) || defined(__NuttX__) || defined(__Fuchsia__) || defined(__wasi__) || \
|
2024-11-06 10:39:19 +01:00
|
|
|
_LIBCPP_HAS_MUSL_LIBC || defined(__OpenBSD__) || defined(__LLVM_LIBC__)
|
2015-08-19 17:21:46 +00:00
|
|
|
# define _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE
|
|
|
|
# endif
|
|
|
|
|
2023-09-07 14:48:45 -04:00
|
|
|
# if __has_feature(cxx_atomic) || __has_extension(c_atomic) || __has_keyword(_Atomic)
|
2024-11-06 10:39:19 +01:00
|
|
|
# define _LIBCPP_HAS_C_ATOMIC_IMP 1
|
|
|
|
# define _LIBCPP_HAS_GCC_ATOMIC_IMP 0
|
|
|
|
# define _LIBCPP_HAS_EXTERNAL_ATOMIC_IMP 0
|
2021-11-17 10:59:31 -05:00
|
|
|
# elif defined(_LIBCPP_COMPILER_GCC)
|
2024-11-06 10:39:19 +01:00
|
|
|
# define _LIBCPP_HAS_C_ATOMIC_IMP 0
|
|
|
|
# define _LIBCPP_HAS_GCC_ATOMIC_IMP 1
|
|
|
|
# define _LIBCPP_HAS_EXTERNAL_ATOMIC_IMP 0
|
2019-03-05 18:40:49 +00:00
|
|
|
# endif
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
|
2024-11-06 10:39:19 +01:00
|
|
|
# if !_LIBCPP_HAS_C_ATOMIC_IMP && !_LIBCPP_HAS_GCC_ATOMIC_IMP && !_LIBCPP_HAS_EXTERNAL_ATOMIC_IMP
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_ATOMIC_HEADER 0
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# else
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_ATOMIC_HEADER 1
|
2019-03-05 18:40:49 +00:00
|
|
|
# ifndef _LIBCPP_ATOMIC_FLAG_TYPE
|
|
|
|
# define _LIBCPP_ATOMIC_FLAG_TYPE bool
|
[libc++][NFC] clang-format <__config>
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
2022-06-13 17:25:23 +02:00
|
|
|
# endif
|
2019-03-05 18:40:49 +00:00
|
|
|
# endif
|
2015-08-19 17:21:46 +00:00
|
|
|
|
2023-07-04 18:11:16 -04:00
|
|
|
# if defined(__FreeBSD__) && defined(__clang__) && __has_attribute(__no_thread_safety_analysis__)
|
|
|
|
# define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS __attribute__((__no_thread_safety_analysis__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NO_THREAD_SAFETY_ANALYSIS
|
|
|
|
# endif
|
|
|
|
|
2017-02-13 15:26:51 +00:00
|
|
|
// Work around the attribute handling in clang. When both __declspec and
|
|
|
|
// __attribute__ are present, the processing goes awry preventing the definition
|
2022-01-11 09:23:39 +00:00
|
|
|
// of the types. In MinGW mode, __declspec evaluates to __attribute__, and thus
|
|
|
|
// combining the two does work.
|
2024-10-12 09:49:52 +02:00
|
|
|
# if defined(_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS) && defined(__clang__) && \
|
|
|
|
__has_attribute(acquire_capability) && !defined(_MSC_VER)
|
|
|
|
# define _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS 0
|
2017-02-13 15:26:51 +00:00
|
|
|
# endif
|
2016-03-16 02:30:06 +00:00
|
|
|
|
2024-10-12 09:49:52 +02:00
|
|
|
# if _LIBCPP_HAS_THREAD_SAFETY_ANNOTATIONS
|
2021-06-04 13:31:22 -04:00
|
|
|
# define _LIBCPP_THREAD_SAFETY_ANNOTATION(x) __attribute__((x))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_THREAD_SAFETY_ANNOTATION(x)
|
|
|
|
# endif
|
2019-12-13 15:42:07 -05:00
|
|
|
|
2023-11-13 13:06:06 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 20
|
|
|
|
# define _LIBCPP_CONSTINIT constinit
|
|
|
|
# elif __has_attribute(__require_constant_initialization__)
|
|
|
|
# define _LIBCPP_CONSTINIT __attribute__((__require_constant_initialization__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_CONSTINIT
|
|
|
|
# endif
|
|
|
|
|
2024-01-22 19:12:05 +01:00
|
|
|
# if defined(__CUDACC__) || defined(__CUDA_ARCH__) || defined(__CUDA_LIBDEVICE__)
|
|
|
|
// 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.
|
|
|
|
# define _LIBCPP_NOINLINE __attribute__((noinline))
|
|
|
|
# elif __has_attribute(__noinline__)
|
|
|
|
# define _LIBCPP_NOINLINE __attribute__((__noinline__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NOINLINE
|
|
|
|
# endif
|
|
|
|
|
2021-08-23 15:32:36 -04:00
|
|
|
// 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.
|
2024-11-06 10:39:19 +01:00
|
|
|
# if !_LIBCPP_HAS_WIDE_CHARACTERS
|
2021-08-23 15:32:36 -04:00
|
|
|
# define _LIBCPP_IF_WIDE_CHARACTERS(...)
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_IF_WIDE_CHARACTERS(...) __VA_ARGS__
|
|
|
|
# endif
|
|
|
|
|
2023-07-06 17:12:05 +00:00
|
|
|
// clang-format off
|
[libc++] Fix missing and incorrect push/pop macros (#79204)
We recently noticed that the unwrap_iter.h file was pushing macros, but
it was pushing them again instead of popping them at the end of the
file. This led to libc++ basically swallowing any custom definition of
these macros in user code:
#define min HELLO
#include <algorithm>
// min is not HELLO anymore, it's not defined
While investigating this issue, I noticed that our push/pop pragmas were
actually entirely wrong too. Indeed, instead of pushing macros like
`move`, we'd push `move(int, int)` in the pragma, which is not a valid
macro name. As a result, we would not actually push macros like `move`
-- instead we'd simply undefine them. This led to the following code not
working:
#define move HELLO
#include <algorithm>
// move is not HELLO anymore
Fixing the pragma push/pop incantations led to a cascade of issues
because we use identifiers like `move` in a large number of places, and
all of these headers would now need to do the push/pop dance.
This patch fixes all these issues. First, it adds a check that we don't
swallow important names like min, max, move or refresh as explained
above. This is done by augmenting the existing
system_reserved_names.gen.py test to also check that the macros are what
we expect after including each header.
Second, it fixes the push/pop pragmas to work properly and adds missing
pragmas to all the files I could detect a failure in via the newly added
test.
rdar://121365472
2024-01-25 15:48:46 -05:00
|
|
|
# define _LIBCPP_PUSH_MACROS _Pragma("push_macro(\"min\")") _Pragma("push_macro(\"max\")") _Pragma("push_macro(\"refresh\")") _Pragma("push_macro(\"move\")") _Pragma("push_macro(\"erase\")")
|
|
|
|
# define _LIBCPP_POP_MACROS _Pragma("pop_macro(\"min\")") _Pragma("pop_macro(\"max\")") _Pragma("pop_macro(\"refresh\")") _Pragma("pop_macro(\"move\")") _Pragma("pop_macro(\"erase\")")
|
2023-07-06 17:12:05 +00:00
|
|
|
// clang-format on
|
2017-05-31 22:07:49 +00:00
|
|
|
|
2018-01-24 04:30:19 +00:00
|
|
|
# ifndef _LIBCPP_NO_AUTO_LINK
|
|
|
|
# if defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_BUILDING_LIBRARY)
|
[libcxx] Base MSVC autolinking on _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
Previously the decision of which library to try to autolink was
based on _DLL, however the _DLL define (which is set by the compiler)
is tied to whether using a dynamically linked CRT or not, and the choice
of dynamic or static CRT is entirely orthogonal to whether libc++ is
linked dynamically or statically.
If _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS isn't defined, then all
declarations are decorated with dllimport, and there's no doubt that
the DLL version of the library is what must be linked.
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS is defined if building with
LIBCXX_ENABLE_SHARED disabled, and thus the static library is what
should be linked.
If defining _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS manually but wanting
to link against the DLL version of the library, that's not a canonical
configuration, and then it's probably reasonable to manually define
_LIBCPP_NO_AUTO_LINK too, and manually link against the desired
library.
This fixes, among other issues, running tests for the library if
built with LIBCXX_ENABLE_STATIC disabled.
Differential Revision: https://reviews.llvm.org/D100539
2021-04-15 11:16:28 +03:00
|
|
|
# if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
|
2018-01-06 18:47:03 +00:00
|
|
|
# pragma comment(lib, "c++.lib")
|
2018-01-24 04:30:19 +00:00
|
|
|
# else
|
2018-01-06 18:47:03 +00:00
|
|
|
# pragma comment(lib, "libc++.lib")
|
2018-01-24 04:30:19 +00:00
|
|
|
# endif
|
|
|
|
# endif // defined(_LIBCPP_ABI_MICROSOFT) && !defined(_LIBCPP_BUILDING_LIBRARY)
|
|
|
|
# endif // _LIBCPP_NO_AUTO_LINK
|
2017-06-16 01:57:41 +00:00
|
|
|
|
2019-09-16 19:26:41 +00:00
|
|
|
// 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.
|
|
|
|
# if defined(__BIONIC__)
|
|
|
|
# define _LIBCPP_FOPEN_CLOEXEC_MODE "e"
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_FOPEN_CLOEXEC_MODE
|
|
|
|
# endif
|
|
|
|
|
2022-02-10 13:23:40 +02:00
|
|
|
# if __has_cpp_attribute(msvc::no_unique_address)
|
|
|
|
// 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.
|
|
|
|
# define _LIBCPP_NO_UNIQUE_ADDRESS [[msvc::no_unique_address]]
|
|
|
|
# else
|
2024-09-03 19:46:08 +02:00
|
|
|
# define _LIBCPP_NO_UNIQUE_ADDRESS [[__no_unique_address__]]
|
2022-02-10 13:23:40 +02:00
|
|
|
# endif
|
|
|
|
|
2022-09-10 10:16:20 -04:00
|
|
|
// 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.
|
2024-10-12 09:49:52 +02:00
|
|
|
//
|
2022-09-10 10:16:20 -04:00
|
|
|
// GNU libc 2.36 and newer declare c8rtomb() and mbrtoc8() in C++ modes if
|
2023-01-25 17:57:15 -05:00
|
|
|
// __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.
|
|
|
|
# if defined(_LIBCPP_GLIBC_PREREQ)
|
|
|
|
# if _LIBCPP_GLIBC_PREREQ(2, 36) && defined(__cpp_char8_t)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 0
|
2022-09-10 10:16:20 -04:00
|
|
|
# endif
|
2024-10-12 09:49:52 +02:00
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_C8RTOMB_MBRTOC8 0
|
2022-09-10 10:16:20 -04:00
|
|
|
# endif
|
|
|
|
|
2022-10-05 19:54:44 +02:00
|
|
|
// 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.
|
2023-02-23 21:17:11 +01:00
|
|
|
# if _LIBCPP_STD_VER >= 17
|
|
|
|
# ifdef _LIBCPP_COMPILER_CLANG_BASED
|
|
|
|
# define _LIBCPP_CTAD_SUPPORTED_FOR_TYPE(_ClassName) \
|
|
|
|
template <class... _Tag> \
|
|
|
|
[[maybe_unused]] _ClassName(typename _Tag::__allow_ctad...)->_ClassName<_Tag...>
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_CTAD_SUPPORTED_FOR_TYPE(ClassName) \
|
|
|
|
template <class... _Tag> \
|
|
|
|
ClassName(typename _Tag::__allow_ctad...)->ClassName<_Tag...>
|
|
|
|
# endif
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_CTAD_SUPPORTED_FOR_TYPE(_ClassName) static_assert(true, "")
|
|
|
|
# endif
|
2022-09-08 17:36:11 -04:00
|
|
|
|
2023-03-02 17:35:03 -08:00
|
|
|
// TODO(varconst): currently, there are bugs in Clang's intrinsics when handling Objective-C++ `id`, so don't use
|
|
|
|
// compiler intrinsics in the Objective-C++ mode.
|
|
|
|
# ifdef __OBJC__
|
|
|
|
# define _LIBCPP_WORKAROUND_OBJCXX_COMPILER_INTRINSICS
|
|
|
|
# endif
|
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# define _PSTL_PRAGMA(x) _Pragma(#x)
|
2023-05-09 11:51:40 -07:00
|
|
|
|
|
|
|
// Enable SIMD for compilers that support OpenMP 4.0
|
2023-06-16 14:32:08 -04:00
|
|
|
# if (defined(_OPENMP) && _OPENMP >= 201307)
|
2023-05-09 11:51:40 -07:00
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# define _PSTL_UDR_PRESENT
|
|
|
|
# define _PSTL_PRAGMA_SIMD _PSTL_PRAGMA(omp simd)
|
|
|
|
# define _PSTL_PRAGMA_DECLARE_SIMD _PSTL_PRAGMA(omp declare simd)
|
|
|
|
# define _PSTL_PRAGMA_SIMD_REDUCTION(PRM) _PSTL_PRAGMA(omp simd reduction(PRM))
|
|
|
|
# define _PSTL_PRAGMA_SIMD_SCAN(PRM) _PSTL_PRAGMA(omp simd reduction(inscan, PRM))
|
|
|
|
# define _PSTL_PRAGMA_SIMD_INCLUSIVE_SCAN(PRM) _PSTL_PRAGMA(omp scan inclusive(PRM))
|
|
|
|
# define _PSTL_PRAGMA_SIMD_EXCLUSIVE_SCAN(PRM) _PSTL_PRAGMA(omp scan exclusive(PRM))
|
2023-05-09 11:51:40 -07:00
|
|
|
|
|
|
|
// 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
|
2023-06-16 14:32:08 -04:00
|
|
|
# define _PSTL_PRAGMA_DECLARE_REDUCTION(NAME, OP) \
|
|
|
|
_PSTL_PRAGMA(omp declare reduction(NAME:OP : omp_out(omp_in)) initializer(omp_priv = omp_orig))
|
2023-05-09 11:51:40 -07:00
|
|
|
|
2023-07-31 18:43:50 -07:00
|
|
|
# elif defined(_LIBCPP_COMPILER_CLANG_BASED)
|
|
|
|
|
|
|
|
# define _PSTL_PRAGMA_SIMD _Pragma("clang loop vectorize(enable) interleave(enable)")
|
|
|
|
# define _PSTL_PRAGMA_DECLARE_SIMD
|
|
|
|
# define _PSTL_PRAGMA_SIMD_REDUCTION(PRM) _Pragma("clang loop vectorize(enable) interleave(enable)")
|
|
|
|
# define _PSTL_PRAGMA_SIMD_SCAN(PRM) _Pragma("clang loop vectorize(enable) interleave(enable)")
|
|
|
|
# define _PSTL_PRAGMA_SIMD_INCLUSIVE_SCAN(PRM)
|
|
|
|
# define _PSTL_PRAGMA_SIMD_EXCLUSIVE_SCAN(PRM)
|
|
|
|
# define _PSTL_PRAGMA_DECLARE_REDUCTION(NAME, OP)
|
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# else // (defined(_OPENMP) && _OPENMP >= 201307)
|
2023-05-09 11:51:40 -07:00
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# define _PSTL_PRAGMA_SIMD
|
|
|
|
# define _PSTL_PRAGMA_DECLARE_SIMD
|
|
|
|
# define _PSTL_PRAGMA_SIMD_REDUCTION(PRM)
|
|
|
|
# define _PSTL_PRAGMA_SIMD_SCAN(PRM)
|
|
|
|
# define _PSTL_PRAGMA_SIMD_INCLUSIVE_SCAN(PRM)
|
|
|
|
# define _PSTL_PRAGMA_SIMD_EXCLUSIVE_SCAN(PRM)
|
|
|
|
# define _PSTL_PRAGMA_DECLARE_REDUCTION(NAME, OP)
|
2023-05-09 11:51:40 -07:00
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# endif // (defined(_OPENMP) && _OPENMP >= 201307)
|
2023-05-09 11:51:40 -07:00
|
|
|
|
2023-06-16 14:32:08 -04:00
|
|
|
# define _PSTL_USE_NONTEMPORAL_STORES_IF_ALLOWED
|
2023-05-09 11:51:40 -07:00
|
|
|
|
2023-11-23 22:15:06 +01:00
|
|
|
// Optional attributes - these are useful for a better QoI, but not required to be available
|
|
|
|
|
|
|
|
# if __has_attribute(__no_sanitize__) && !defined(_LIBCPP_COMPILER_GCC)
|
|
|
|
# define _LIBCPP_NO_CFI __attribute__((__no_sanitize__("cfi")))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NO_CFI
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__malloc__)
|
|
|
|
# define _LIBCPP_NOALIAS __attribute__((__malloc__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NOALIAS
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__using_if_exists__)
|
|
|
|
# define _LIBCPP_USING_IF_EXISTS __attribute__((__using_if_exists__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_USING_IF_EXISTS
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__no_destroy__)
|
|
|
|
# define _LIBCPP_NO_DESTROY __attribute__((__no_destroy__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NO_DESTROY
|
|
|
|
# endif
|
|
|
|
|
2024-05-01 10:26:38 -06:00
|
|
|
# if __has_attribute(__diagnose_if__)
|
2023-11-23 22:15:06 +01:00
|
|
|
# define _LIBCPP_DIAGNOSE_WARNING(...) __attribute__((__diagnose_if__(__VA_ARGS__, "warning")))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DIAGNOSE_WARNING(...)
|
|
|
|
# endif
|
|
|
|
|
|
|
|
// Use a function like macro to imply that it must be followed by a semicolon
|
|
|
|
# if __has_cpp_attribute(fallthrough)
|
|
|
|
# define _LIBCPP_FALLTHROUGH() [[fallthrough]]
|
|
|
|
# elif __has_attribute(__fallthrough__)
|
|
|
|
# define _LIBCPP_FALLTHROUGH() __attribute__((__fallthrough__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_FALLTHROUGH() ((void)0)
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_cpp_attribute(_Clang::__lifetimebound__)
|
|
|
|
# define _LIBCPP_LIFETIMEBOUND [[_Clang::__lifetimebound__]]
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_LIFETIMEBOUND
|
|
|
|
# endif
|
|
|
|
|
2024-10-25 09:04:42 +08:00
|
|
|
# if __has_cpp_attribute(_Clang::__noescape__)
|
|
|
|
# define _LIBCPP_NOESCAPE [[_Clang::__noescape__]]
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NOESCAPE
|
|
|
|
# endif
|
|
|
|
|
2025-01-17 18:17:21 +01:00
|
|
|
# define _LIBCPP_NODEBUG [[__gnu__::__nodebug__]]
|
2023-11-23 22:15:06 +01:00
|
|
|
|
2025-01-23 13:18:54 +01:00
|
|
|
# if __has_cpp_attribute(_Clang::__no_specializations__)
|
|
|
|
# define _LIBCPP_NO_SPECIALIZATIONS \
|
|
|
|
[[_Clang::__no_specializations__("Users are not allowed to specialize this standard library entity")]]
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NO_SPECIALIZATIONS
|
|
|
|
# endif
|
|
|
|
|
2023-11-23 22:15:06 +01:00
|
|
|
# if __has_attribute(__standalone_debug__)
|
|
|
|
# define _LIBCPP_STANDALONE_DEBUG __attribute__((__standalone_debug__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_STANDALONE_DEBUG
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__preferred_name__)
|
|
|
|
# define _LIBCPP_PREFERRED_NAME(x) __attribute__((__preferred_name__(x)))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_PREFERRED_NAME(x)
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__no_sanitize__)
|
|
|
|
# define _LIBCPP_NO_SANITIZE(...) __attribute__((__no_sanitize__(__VA_ARGS__)))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_NO_SANITIZE(...)
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__init_priority__)
|
|
|
|
# define _LIBCPP_INIT_PRIORITY_MAX __attribute__((__init_priority__(100)))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_INIT_PRIORITY_MAX
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__format__)
|
|
|
|
// The attribute uses 1-based indices for ordinary and static member functions.
|
|
|
|
// The attribute uses 2-based indices for non-static member functions.
|
|
|
|
# define _LIBCPP_ATTRIBUTE_FORMAT(archetype, format_string_index, first_format_arg_index) \
|
|
|
|
__attribute__((__format__(archetype, format_string_index, first_format_arg_index)))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_ATTRIBUTE_FORMAT(archetype, format_string_index, first_format_arg_index) /* nothing */
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if __has_attribute(__packed__)
|
|
|
|
# define _LIBCPP_PACKED __attribute__((__packed__))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_PACKED
|
|
|
|
# endif
|
|
|
|
|
|
|
|
# if defined(_LIBCPP_ABI_MICROSOFT) && __has_declspec_attribute(empty_bases)
|
|
|
|
# define _LIBCPP_DECLSPEC_EMPTY_BASES __declspec(empty_bases)
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DECLSPEC_EMPTY_BASES
|
|
|
|
# endif
|
|
|
|
|
|
|
|
// Allow for build-time disabling of unsigned integer sanitization
|
|
|
|
# if __has_attribute(no_sanitize) && !defined(_LIBCPP_COMPILER_GCC)
|
|
|
|
# define _LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK __attribute__((__no_sanitize__("unsigned-integer-overflow")))
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_DISABLE_UBSAN_UNSIGNED_INTEGER_CHECK
|
|
|
|
# endif
|
|
|
|
|
2024-01-21 07:16:51 +02:00
|
|
|
// Clang-18 has support for deducing this, but it does not set the FTM.
|
|
|
|
# if defined(__cpp_explicit_this_parameter) || (defined(_LIBCPP_CLANG_VER) && _LIBCPP_CLANG_VER >= 1800)
|
2024-10-12 09:49:52 +02:00
|
|
|
# define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 1
|
|
|
|
# else
|
|
|
|
# define _LIBCPP_HAS_EXPLICIT_THIS_PARAMETER 0
|
2024-01-21 07:16:51 +02:00
|
|
|
# endif
|
|
|
|
|
2017-06-16 01:57:41 +00:00
|
|
|
#endif // __cplusplus
|
|
|
|
|
2022-03-23 13:11:04 -04:00
|
|
|
#endif // _LIBCPP___CONFIG
|