maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/include/__availability

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

274 lines
15 KiB
Plaintext
Raw Normal View History

[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
// -*- C++ -*-
//===----------------------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#ifndef _LIBCPP___AVAILABILITY
#define _LIBCPP___AVAILABILITY
#include <__config>
#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
[libc++] Normalize all our '#pragma GCC system_header', and regression-test. Now we'll notice if a header forgets to include this magic phrase. Differential Revision: https://reviews.llvm.org/D118800
2022-02-02 09:16:40 +08:00
# pragma GCC system_header
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
#endif
// Libc++ is shipped by various vendors. In particular, it is used as a system
// library on macOS, iOS and other Apple platforms. In order for users to be
// able to compile a binary that is intended to be deployed to an older version
// of a platform, Clang provides availability attributes [1]. These attributes
// can be placed on declarations and are used to describe the life cycle of a
// symbol in the library.
//
// The main goal is to ensure a compile-time error if a symbol that hasn't been
// introduced in a previously released library is used in a program that targets
// that previously released library. Normally, this would be a load-time error
// when one tries to launch the program against the older library.
//
// For example, the filesystem library was introduced in the dylib in macOS 10.15.
// If a user compiles on a macOS 10.15 host but targets macOS 10.13 with their
// program, the compiler would normally not complain (because the required
// declarations are in the headers), but the dynamic loader would fail to find
// the symbols when actually trying to launch the program on macOS 10.13. To
// turn this into a compile-time issue instead, declarations are annotated with
// when they were introduced, and the compiler can produce a diagnostic if the
// program references something that isn't available on the deployment target.
//
// This mechanism is general in nature, and any vendor can add their markup to
// the library (see below). Whenever a new feature is added that requires support
// in the shared library, a macro should be added below to mark this feature
// as unavailable. When vendors decide to ship the feature as part of their
// shared library, they can update the markup appropriately.
//
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
// Furthermore, many features in the standard library have corresponding
// feature-test macros. When a feature is made unavailable on some deployment
// target, a macro should be defined to signal that it is unavailable. That
// macro can then be picked up when feature-test macros are generated (see
// generate_feature_test_macro_components.py) to make sure that feature-test
// macros don't announce a feature as being implemented if it has been marked
// as unavailable.
//
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
// Note that this mechanism is disabled by default in the "upstream" libc++.
// Availability annotations are only meaningful when shipping libc++ inside
// a platform (i.e. as a system library), and so vendors that want them should
// turn those annotations on at CMake configuration time.
//
// [1]: https://clang.llvm.org/docs/AttributeReference.html#availability
// For backwards compatibility, allow users to define _LIBCPP_DISABLE_AVAILABILITY
// for a while.
#if defined(_LIBCPP_DISABLE_AVAILABILITY)
# if !defined(_LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS)
# define _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS
# endif
#endif
// Availability markup is disabled when building the library, or when the compiler
// doesn't support the proper attributes.
#if defined(_LIBCPP_BUILDING_LIBRARY) || \
defined(_LIBCXXABI_BUILDING_LIBRARY) || \
!__has_feature(attribute_availability_with_strict) || \
!__has_feature(attribute_availability_in_templates) || \
!__has_extension(pragma_clang_attribute_external_declaration)
# if !defined(_LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS)
# define _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS
# endif
#endif
#if defined(_LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS)
// This controls the availability of std::shared_mutex and std::shared_timed_mutex,
// which were added to the dylib later.
# define _LIBCPP_AVAILABILITY_SHARED_MUTEX
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_shared_mutex
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_shared_timed_mutex
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
// These macros control the availability of std::bad_optional_access and
// other exception types. These were put in the shared library to prevent
// code bloat from every user program defining the vtable for these exception
// types.
# define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS
# define _LIBCPP_AVAILABILITY_BAD_VARIANT_ACCESS
# define _LIBCPP_AVAILABILITY_BAD_ANY_CAST
// This controls the availability of std::uncaught_exceptions().
# define _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS
// This controls the availability of the sized version of ::operator delete,
// which was added to the dylib later.
# define _LIBCPP_AVAILABILITY_SIZED_NEW_DELETE
// This controls the availability of the std::future_error exception.
# define _LIBCPP_AVAILABILITY_FUTURE_ERROR
// This controls the availability of std::type_info's vtable.
// I can't imagine how using std::type_info can work at all if
// this isn't supported.
# define _LIBCPP_AVAILABILITY_TYPEINFO_VTABLE
// This controls the availability of std::locale::category members
// (e.g. std::locale::collate), which are defined in the dylib.
# define _LIBCPP_AVAILABILITY_LOCALE_CATEGORY
// This controls the availability of atomic operations on std::shared_ptr
// (e.g. `std::atomic_store(std::shared_ptr)`), which require a shared
// lock table located in the dylib.
# define _LIBCPP_AVAILABILITY_ATOMIC_SHARED_PTR
// These macros control the availability of all parts of <filesystem> that
// depend on something in the dylib.
# define _LIBCPP_AVAILABILITY_FILESYSTEM
# define _LIBCPP_AVAILABILITY_FILESYSTEM_PUSH
# define _LIBCPP_AVAILABILITY_FILESYSTEM_POP
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_filesystem
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
// This controls the availability of std::to_chars.
# define _LIBCPP_AVAILABILITY_TO_CHARS
Microsoft's floating-point to_chars powered by Ryu and Ryu Printf Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu . Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License. This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes . Notes: * libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything. * Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars. * This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit. * I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.) * Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster). * The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them. * You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size. * See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.) Differential Revision: https://reviews.llvm.org/D70631
2021-02-10 00:52:41 +08:00
// This controls the availability of floating-point std::to_chars functions.
// These overloads were added later than the integer overloads.
# define _LIBCPP_AVAILABILITY_TO_CHARS_FLOATING_POINT
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
// This controls the availability of the C++20 synchronization library,
// which requires shared library support for various operations
// (see libcxx/src/atomic.cpp).
# define _LIBCPP_AVAILABILITY_SYNC
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_atomic_wait
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_barrier
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_latch
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_semaphore
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
[libc++][format] Adds availability macros for std::format. This prevents std::format to be available until there's an ABI stable version. (This only impacts the Apple platform.) Depends on D102703 Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D102705
2021-05-19 02:00:22 +08:00
// This controls the availability of the C++20 format library.
[libc++][format] Add __format_arg_store. This implements the struct `__format_arg_store` and its dependencies: * the class basic_format_arg, * the class basic_format_args, * the class basic_format_context, * the function make_format_args, * the function wmake_format_args, * the function visit_format_arg, * several Standard required typedefs. The following parts will be implemented in a later patch: * the child class `basic_format_arg::handle`, * the function `basic_format_arg::basic_format_arg(const T* p)`. The following extension has been implemented: * the class basic_format_arg supports `__[u]int128_t` on platform where libc++ supports 128 bit integrals. Implements parts of: * P0645 Text Formatting Completes: * LWG3371 visit_format_arg and make_format_args are not hidden friends * LWG3542 basic_format_arg mishandles basic_string_view with custom traits Note https://mordante.github.io/blog/2021/06/05/format.html gives a bit more information about the goals and non-goals of this initial patch series. Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103357
2020-12-05 18:45:21 +08:00
// The library is in development and not ABI stable yet. P2216 is
// retroactively accepted in C++20. This paper contains ABI breaking
// changes.
[libc++][format] Adds availability macros for std::format. This prevents std::format to be available until there's an ABI stable version. (This only impacts the Apple platform.) Depends on D102703 Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D102705
2021-05-19 02:00:22 +08:00
# define _LIBCPP_AVAILABILITY_FORMAT
// # define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_format
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
#elif defined(__APPLE__)
# define _LIBCPP_AVAILABILITY_SHARED_MUTEX \
__attribute__((availability(macosx,strict,introduced=10.12))) \
__attribute__((availability(ios,strict,introduced=10.0))) \
__attribute__((availability(tvos,strict,introduced=10.0))) \
__attribute__((availability(watchos,strict,introduced=3.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101200) || \
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 100000) || \
(defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ < 100000) || \
(defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ < 30000)
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_shared_mutex
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_shared_timed_mutex
# endif
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS \
__attribute__((availability(macosx,strict,introduced=10.13))) \
__attribute__((availability(ios,strict,introduced=11.0))) \
__attribute__((availability(tvos,strict,introduced=11.0))) \
__attribute__((availability(watchos,strict,introduced=4.0)))
# define _LIBCPP_AVAILABILITY_BAD_VARIANT_ACCESS \
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS
# define _LIBCPP_AVAILABILITY_BAD_ANY_CAST \
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS \
__attribute__((availability(macosx,strict,introduced=10.12))) \
__attribute__((availability(ios,strict,introduced=10.0))) \
__attribute__((availability(tvos,strict,introduced=10.0))) \
__attribute__((availability(watchos,strict,introduced=3.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_SIZED_NEW_DELETE \
__attribute__((availability(macosx,strict,introduced=10.12))) \
__attribute__((availability(ios,strict,introduced=10.0))) \
__attribute__((availability(tvos,strict,introduced=10.0))) \
__attribute__((availability(watchos,strict,introduced=3.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_FUTURE_ERROR \
__attribute__((availability(ios,strict,introduced=6.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_TYPEINFO_VTABLE \
__attribute__((availability(macosx,strict,introduced=10.9))) \
__attribute__((availability(ios,strict,introduced=7.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_LOCALE_CATEGORY \
__attribute__((availability(macosx,strict,introduced=10.9))) \
__attribute__((availability(ios,strict,introduced=7.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_ATOMIC_SHARED_PTR \
__attribute__((availability(macosx,strict,introduced=10.9))) \
__attribute__((availability(ios,strict,introduced=7.0)))
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_FILESYSTEM \
__attribute__((availability(macosx,strict,introduced=10.15))) \
__attribute__((availability(ios,strict,introduced=13.0))) \
__attribute__((availability(tvos,strict,introduced=13.0))) \
__attribute__((availability(watchos,strict,introduced=6.0)))
# define _LIBCPP_AVAILABILITY_FILESYSTEM_PUSH \
_Pragma("clang attribute push(__attribute__((availability(macosx,strict,introduced=10.15))), apply_to=any(function,record))") \
_Pragma("clang attribute push(__attribute__((availability(ios,strict,introduced=13.0))), apply_to=any(function,record))") \
_Pragma("clang attribute push(__attribute__((availability(tvos,strict,introduced=13.0))), apply_to=any(function,record))") \
_Pragma("clang attribute push(__attribute__((availability(watchos,strict,introduced=6.0))), apply_to=any(function,record))")
# define _LIBCPP_AVAILABILITY_FILESYSTEM_POP \
_Pragma("clang attribute pop") \
_Pragma("clang attribute pop") \
_Pragma("clang attribute pop") \
_Pragma("clang attribute pop")
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101500) || \
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 130000) || \
(defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ < 130000) || \
(defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ < 60000)
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_filesystem
# endif
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_TO_CHARS \
_LIBCPP_AVAILABILITY_FILESYSTEM
[libc++] Make feature-test macros consistent with availability macros Before this patch, feature-test macros didn't take special availability markup into account, which means that feature-test macros can sometimes appear to "lie". For example, if you compile in C++20 mode and target macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided even though the <filesystem> declarations are marked as unavailable. This patch fixes that. rdar://68142369 Differential Revision: https://reviews.llvm.org/D94983
2021-01-20 02:04:01 +08:00
Microsoft's floating-point to_chars powered by Ryu and Ryu Printf Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu . Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License. This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes . Notes: * libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything. * Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars. * This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit. * I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.) * Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster). * The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them. * You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size. * See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.) Differential Revision: https://reviews.llvm.org/D70631
2021-02-10 00:52:41 +08:00
# define _LIBCPP_AVAILABILITY_TO_CHARS_FLOATING_POINT \
__attribute__((unavailable))
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
# define _LIBCPP_AVAILABILITY_SYNC \
[libc++] Enable the synchronization library on Apple platforms The synchronization library was marked as disabled on Apple platforms up to now because we were not 100% sure that it was going to be ABI stable. However, it's been some time since we shipped it in upstream libc++ now and there's been no changes so far. This patch enables the synchronization library on Apple platforms, and hence commits the ABI stability as far as that vendor is concerned. Differential Revision: https://reviews.llvm.org/D96790
2021-02-17 00:24:27 +08:00
__attribute__((availability(macosx,strict,introduced=11.0))) \
__attribute__((availability(ios,strict,introduced=14.0))) \
__attribute__((availability(tvos,strict,introduced=14.0))) \
__attribute__((availability(watchos,strict,introduced=7.0)))
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 110000) || \
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 140000) || \
(defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ < 140000) || \
(defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ < 70000)
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_atomic_wait
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_barrier
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_latch
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_semaphore
# endif
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
[libc++][format] Adds availability macros for std::format. This prevents std::format to be available until there's an ABI stable version. (This only impacts the Apple platform.) Depends on D102703 Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D102705
2021-05-19 02:00:22 +08:00
# define _LIBCPP_AVAILABILITY_FORMAT \
__attribute__((unavailable))
# define _LIBCPP_AVAILABILITY_DISABLE_FTM___cpp_lib_format
[libc++] Rework the whole availability markup implementation Currently, vendor-specific availability markup is enabled by default. This means that even when building against trunk libc++, the headers will by default prevent you from using some features that were not released in the dylib on your target platform. This is a source of frustration since people building libc++ from sources are usually not trying to use some vendor's released dylib. For that reason, I've been thinking for a long time that availability annotations should be off by default, which is the primary change that this commit enables. In addition, it reworks the implementation to make it easier for new vendors to add availability annotations for their platform, and it refreshes the documentation to reflect the current state of the codebase. Finally, a CMake configuration option is added to control whether availability annotations should be turned on for the flavor of libc++ being created. The intent is for vendors like Apple to turn it on, and for the upstream libc++ to leave it off (the default). Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 04:01:25 +08:00
#else
// ...New vendors can add availability markup here...
# error "It looks like you're trying to enable vendor availability markup, but you haven't defined the corresponding macros yet!"
#endif
// Define availability attributes that depend on _LIBCPP_NO_EXCEPTIONS.
// Those are defined in terms of the availability attributes above, and
// should not be vendor-specific.
#if defined(_LIBCPP_NO_EXCEPTIONS)
# define _LIBCPP_AVAILABILITY_FUTURE
# define _LIBCPP_AVAILABILITY_THROW_BAD_ANY_CAST
# define _LIBCPP_AVAILABILITY_THROW_BAD_OPTIONAL_ACCESS
# define _LIBCPP_AVAILABILITY_THROW_BAD_VARIANT_ACCESS
#else
# define _LIBCPP_AVAILABILITY_FUTURE _LIBCPP_AVAILABILITY_FUTURE_ERROR
# define _LIBCPP_AVAILABILITY_THROW_BAD_ANY_CAST _LIBCPP_AVAILABILITY_BAD_ANY_CAST
# define _LIBCPP_AVAILABILITY_THROW_BAD_OPTIONAL_ACCESS _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS
# define _LIBCPP_AVAILABILITY_THROW_BAD_VARIANT_ACCESS _LIBCPP_AVAILABILITY_BAD_VARIANT_ACCESS
#endif
[libc++] NFC: Normalize `#endif //` comment indentation
2021-04-21 00:03:32 +08:00
#endif // _LIBCPP___AVAILABILITY