mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-30 08:26:07 +00:00
Code Issues Projects 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.

307 lines
17 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-04 15:01:25 -05: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-01 20:16:40 -05: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-04 15:01:25 -05: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
[libc++] Systematically define a macro to check whether a feature is unavailable Previously, we inconsistently defined whether a feature was unavailable on a given deployment target. We would have availability attributes for all features, but only some features had the equivalent of a _HAS_NO_FOO macro in the form of the DISABLE_FTM___foo macros. Instead, systematically define a _HAS_NO_FOO macro, which makes it easier to understand how to add availability markup for a new platform. Differential Revision: https://reviews.llvm.org/D147226
2023-03-30 08:51:13 -04:00
// in the shared library, two macros are added below to allow marking the feature
// as unavailable:
// 1. A macro named `_LIBCPP_AVAILABILITY_HAS_NO_<feature>` which must be defined
// exactly when compiling for a target that doesn't support the feature.
// 2. A macro named `_LIBCPP_AVAILABILITY_<feature>`, which must always be defined
// and must expand to the proper availability attribute for the platform.
//
// When vendors decide to ship the feature as part of their shared library, they
// can update these macros appropriately for their platform, and the library will
// use those to provide an optimal user experience.
[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-04 15:01:25 -05:00
//
[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-19 13:04:01 -05:00
// Furthermore, many features in the standard library have corresponding
[libc++] Systematically define a macro to check whether a feature is unavailable Previously, we inconsistently defined whether a feature was unavailable on a given deployment target. We would have availability attributes for all features, but only some features had the equivalent of a _HAS_NO_FOO macro in the form of the DISABLE_FTM___foo macros. Instead, systematically define a _HAS_NO_FOO macro, which makes it easier to understand how to add availability markup for a new platform. Differential Revision: https://reviews.llvm.org/D147226
2023-03-30 08:51:13 -04:00
// feature-test macros. The `_LIBCPP_AVAILABILITY_HAS_NO_<feature>` macros
// are checked by the corresponding feature-test macros generated by
// generate_feature_test_macro_components.py to ensure that the library
// doesn't announce a feature as being implemented if it is unavailable on
// the deployment target.
[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-19 13:04:01 -05: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-04 15:01:25 -05: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)
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01: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.
//
// Note that when exceptions are disabled, the methods that normally throw
// these exceptions can be used even on older deployment targets, but those
// methods will abort instead of throwing.
# define _LIBCPP_AVAILABILITY_HAS_BAD_OPTIONAL_ACCESS 1
# define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS
# define _LIBCPP_AVAILABILITY_HAS_BAD_VARIANT_ACCESS 1
# define _LIBCPP_AVAILABILITY_BAD_VARIANT_ACCESS
# define _LIBCPP_AVAILABILITY_HAS_BAD_ANY_CAST 1
# define _LIBCPP_AVAILABILITY_BAD_ANY_CAST
// These macros control the availability of all parts of <filesystem> that
// depend on something in the dylib.
# define _LIBCPP_AVAILABILITY_HAS_FILESYSTEM_LIBRARY 1
# define _LIBCPP_AVAILABILITY_FILESYSTEM_LIBRARY
# define _LIBCPP_AVAILABILITY_FILESYSTEM_LIBRARY_PUSH
# define _LIBCPP_AVAILABILITY_FILESYSTEM_LIBRARY_POP
// This controls the availability of floating-point std::to_chars functions.
// These overloads were added later than the integer overloads.
# define _LIBCPP_AVAILABILITY_HAS_TO_CHARS_FLOATING_POINT 1
# define _LIBCPP_AVAILABILITY_TO_CHARS_FLOATING_POINT
// This controls the availability of the C++20 synchronization library,
// which requires shared library support for various operations
// (see libcxx/src/atomic.cpp). This includes <barier>, <latch>,
// <semaphore>, and notification functions on std::atomic.
# define _LIBCPP_AVAILABILITY_HAS_SYNC 1
# define _LIBCPP_AVAILABILITY_SYNC
// This controls whether the library claims to provide a default verbose
// termination function, and consequently whether the headers will try
// to use it when the mechanism isn't overriden at compile-time.
# define _LIBCPP_AVAILABILITY_HAS_VERBOSE_ABORT 1
# define _LIBCPP_AVAILABILITY_VERBOSE_ABORT
// This controls the availability of the C++17 std::pmr library,
// which is implemented in large part in the built library.
# define _LIBCPP_AVAILABILITY_HAS_PMR 1
# define _LIBCPP_AVAILABILITY_PMR
// This controls the availability of the C++20 time zone database.
// The parser code is built in the library.
# define _LIBCPP_AVAILABILITY_HAS_TZDB 1
# define _LIBCPP_AVAILABILITY_TZDB
[libc++][chrono] Adds tzdb_list implementation. This is the first step to implement time zone support in libc++. This adds the complete tzdb_list class and a minimal tzdb class. The tzdb class only contains the version, which is used by reload_tzdb. Next to these classes it contains documentation and build system support needed for time zone support. The code depends on the IANA Time Zone Database, which should be available on the platform used or provided by the libc++ vendors. The code is labeled as experimental since there will be ABI breaks during development; the tzdb class needs to have the standard headers. Implements parts of: - P0355 Extending <chrono> to Calendars and Time Zones Addresses: - LWG3319 Properly reference specification of IANA time zone database Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D154282
2022-09-23 18:33:20 +02:00
[libc++][print] Adds ostream overloads. (#73262) Finishes implementation of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Differential Revision: https://reviews.llvm.org/D156609
2023-12-19 19:32:17 +01:00
// This controls the availability of C++23 <print>, which
// has a dependency on the built library (it needs access to
// the underlying buffer types of std::cout, std::cerr, and std::clog.
# define _LIBCPP_AVAILABILITY_HAS_PRINT 1
# define _LIBCPP_AVAILABILITY_PRINT
[libc++] Recategorize additional instantiations in the dylib as availability macros Adding additional instantiations to the dylib isn't actually an ABI break as long as programs targeting an older dylib don't start to depend on them. Making additional instantiations a matter of availability allows us to add them without an ABI break. Reviewed By: #libc, ldionne, Mordante Spies: arichardson, ldionne, Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D154796
2023-09-14 21:17:15 +02:00
// Enable additional explicit instantiations of iostreams components. This
// reduces the number of weak definitions generated in programs that use
// iostreams by providing a single strong definition in the shared library.
//
// TODO: Enable additional explicit instantiations on GCC once it supports exclude_from_explicit_instantiation,
// or once libc++ doesn't use the attribute anymore.
// TODO: Enable them on Windows once https://llvm.org/PR41018 has been fixed.
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# if !defined(_LIBCPP_COMPILER_GCC) && !defined(_WIN32)
# define _LIBCPP_AVAILABILITY_HAS_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1 1
# else
# define _LIBCPP_AVAILABILITY_HAS_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1 0
# endif
[libc++] Recategorize additional instantiations in the dylib as availability macros Adding additional instantiations to the dylib isn't actually an ABI break as long as programs targeting an older dylib don't start to depend on them. Making additional instantiations a matter of availability allows us to add them without an ABI break. Reviewed By: #libc, ldionne, Mordante Spies: arichardson, ldionne, Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D154796
2023-09-14 21:17:15 +02: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-04 15:01:25 -05:00
#elif defined(__APPLE__)
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_BAD_OPTIONAL_ACCESS \
(!defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) || __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ >= 50000)
# define _LIBCPP_AVAILABILITY_HAS_BAD_VARIANT_ACCESS _LIBCPP_AVAILABILITY_HAS_BAD_OPTIONAL_ACCESS
# define _LIBCPP_AVAILABILITY_HAS_BAD_ANY_CAST _LIBCPP_AVAILABILITY_HAS_BAD_OPTIONAL_ACCESS
[libc++] Remove availability annotations which can never be triggered (#69226) According to https://developer.apple.com/support/xcode/, quite a few of our availability macros don't do anything anymore, so we might as well remove them to clean up the code a bit.
2023-11-01 23:56:43 +01:00
# define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS __attribute__((availability(watchos, strict, introduced = 5.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-19 13:04:01 -05:00
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
// <filesystem>
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format off
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01: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)
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format on
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_FILESYSTEM_LIBRARY 0
# else
# define _LIBCPP_AVAILABILITY_HAS_FILESYSTEM_LIBRARY 1
# endif
[libc++] Rename availability macros for <filesystem> This makes it clearer that the availability macro only pertains to <filesystem>, and not to whether the platform has support for a file system. Differential Revision: https://reviews.llvm.org/D152172
2023-06-05 08:20:39 -07:00
# define _LIBCPP_AVAILABILITY_FILESYSTEM_LIBRARY \
[libc++][NFC] Change availability macro from macosx to macos The Clang documentation mentions that macosx is supported for backwards compatibility, but it's deprecated.
2022-03-23 13:12:55 -04:00
__attribute__((availability(macos, strict, introduced = 10.15))) \
[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-04 15:01:25 -05:00
__attribute__((availability(ios, strict, introduced = 13.0))) \
__attribute__((availability(tvos, strict, introduced = 13.0))) \
__attribute__((availability(watchos, strict, introduced = 6.0)))
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format off
[libc++] Rename availability macros for <filesystem> This makes it clearer that the availability macro only pertains to <filesystem>, and not to whether the platform has support for a file system. Differential Revision: https://reviews.llvm.org/D152172
2023-06-05 08:20:39 -07:00
# define _LIBCPP_AVAILABILITY_FILESYSTEM_LIBRARY_PUSH \
[libc++][NFC] Change availability macro from macosx to macos The Clang documentation mentions that macosx is supported for backwards compatibility, but it's deprecated.
2022-03-23 13:12:55 -04:00
_Pragma("clang attribute push(__attribute__((availability(macos,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))") \
[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-04 15:01:25 -05:00
_Pragma("clang attribute push(__attribute__((availability(watchos,strict,introduced=6.0))), apply_to=any(function,record))")
[libc++] Rename availability macros for <filesystem> This makes it clearer that the availability macro only pertains to <filesystem>, and not to whether the platform has support for a file system. Differential Revision: https://reviews.llvm.org/D152172
2023-06-05 08:20:39 -07:00
# define _LIBCPP_AVAILABILITY_FILESYSTEM_LIBRARY_POP \
[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-04 15:01:25 -05:00
_Pragma("clang attribute pop") \
_Pragma("clang attribute pop") \
_Pragma("clang attribute pop") \
_Pragma("clang attribute pop")
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format on
[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-19 13:04:01 -05:00
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
// std::to_chars(floating-point)
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format off
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 130300) || \
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 160300) || \
(defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ < 160300) || \
(defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ < 90300)
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format on
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_TO_CHARS_FLOATING_POINT 0
# else
# define _LIBCPP_AVAILABILITY_HAS_TO_CHARS_FLOATING_POINT 1
# endif
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-09 17:52:41 +01:00
# define _LIBCPP_AVAILABILITY_TO_CHARS_FLOATING_POINT \
[libc++][Apple] Update availability markup for std::to_chars(floating-point) Differential Revision: https://reviews.llvm.org/D146367
2023-03-18 16:46:54 -04:00
__attribute__((availability(macos, strict, introduced = 13.3))) \
__attribute__((availability(ios, strict, introduced = 16.3))) \
__attribute__((availability(tvos, strict, introduced = 16.3))) \
__attribute__((availability(watchos, strict, introduced = 9.3)))
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-09 17:52:41 +01:00
[libc++] Systematically define a macro to check whether a feature is unavailable Previously, we inconsistently defined whether a feature was unavailable on a given deployment target. We would have availability attributes for all features, but only some features had the equivalent of a _HAS_NO_FOO macro in the form of the DISABLE_FTM___foo macros. Instead, systematically define a _HAS_NO_FOO macro, which makes it easier to understand how to add availability markup for a new platform. Differential Revision: https://reviews.llvm.org/D147226
2023-03-30 08:51:13 -04:00
// c++20 synchronization library
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format off
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# 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)
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format on
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_SYNC 0
# else
# define _LIBCPP_AVAILABILITY_HAS_SYNC 1
[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-16 11:24:27 -05:00
# endif
[libc++] Systematically define a macro to check whether a feature is unavailable Previously, we inconsistently defined whether a feature was unavailable on a given deployment target. We would have availability attributes for all features, but only some features had the equivalent of a _HAS_NO_FOO macro in the form of the DISABLE_FTM___foo macros. Instead, systematically define a _HAS_NO_FOO macro, which makes it easier to understand how to add availability markup for a new platform. Differential Revision: https://reviews.llvm.org/D147226
2023-03-30 08:51:13 -04:00
# define _LIBCPP_AVAILABILITY_SYNC \
__attribute__((availability(macos, 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)))
[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-04 15:01:25 -05:00
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
// __libcpp_verbose_abort
// TODO: Update once this is released
# define _LIBCPP_AVAILABILITY_HAS_VERBOSE_ABORT 0
[libc++] Systematically define a macro to check whether a feature is unavailable Previously, we inconsistently defined whether a feature was unavailable on a given deployment target. We would have availability attributes for all features, but only some features had the equivalent of a _HAS_NO_FOO macro in the form of the DISABLE_FTM___foo macros. Instead, systematically define a _HAS_NO_FOO macro, which makes it easier to understand how to add availability markup for a new platform. Differential Revision: https://reviews.llvm.org/D147226
2023-03-30 08:51:13 -04:00
# define _LIBCPP_AVAILABILITY_VERBOSE_ABORT __attribute__((unavailable))
[libc++] Allow enabling assertions when back-deploying When back-deploying to older platforms, we can still provide assertions, but we might not be able to provide a great implementation for the verbose handler. Instead, we can just call ::abort(). Differential Revision: https://reviews.llvm.org/D131199
2022-08-04 15:25:48 -04:00
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
// std::pmr
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format off
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 140000) || \
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 170000) || \
(defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ < 170000) || \
(defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ < 100000)
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format on
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_PMR 0
# else
# define _LIBCPP_AVAILABILITY_HAS_PMR 1
# endif
[libc++] Add incomplete availability markup for std::pmr This fixes rdar://110330781, which asked for the feature-test macro for std::pmr to take into account the deployment target. It doesn't fix https://llvm.org/PR62212, though, because the availability markup itself must be disabled until some Clang bugs have been fixed. This is pretty vexing, however at least everything should work once those Clang bugs have been fixed. In the meantime, this patch at least adds the required markup (as disabled) and ensures that the feature-test macro for std::pmr is aware of the deployment target requirement. Differential Revision: https://reviews.llvm.org/D135813
2023-03-29 16:48:20 -04:00
// TODO: Enable std::pmr markup once https://github.com/llvm/llvm-project/issues/40340 has been fixed
// Until then, it is possible for folks to try to use `std::pmr` when back-deploying to targets that don't support
// it and it'll be a load-time error, but we don't have a good alternative because the library won't compile if we
// use availability annotations until that bug has been fixed.
# if 0
# define _LIBCPP_AVAILABILITY_PMR \
__attribute__((availability(macos, strict, introduced = 14.0))) \
__attribute__((availability(ios, strict, introduced = 17.0))) \
__attribute__((availability(tvos, strict, introduced = 17.0))) \
__attribute__((availability(watchos, strict, introduced = 10.0)))
# else
# define _LIBCPP_AVAILABILITY_PMR
# endif
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_TZDB 0
[libc++][chrono] Adds tzdb_list implementation. This is the first step to implement time zone support in libc++. This adds the complete tzdb_list class and a minimal tzdb class. The tzdb class only contains the version, which is used by reload_tzdb. Next to these classes it contains documentation and build system support needed for time zone support. The code depends on the IANA Time Zone Database, which should be available on the platform used or provided by the libc++ vendors. The code is labeled as experimental since there will be ABI breaks during development; the tzdb class needs to have the standard headers. Implements parts of: - P0355 Extending <chrono> to Calendars and Time Zones Addresses: - LWG3319 Properly reference specification of IANA time zone database Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D154282
2022-09-23 18:33:20 +02:00
# define _LIBCPP_AVAILABILITY_TZDB __attribute__((unavailable))
[libc++][print] Enables it on Apple backdeployment. (#76293) As suggested in #73262 this enable the stream printing on Apple backdeployment targets. This omits the check whether the file is a terminal. This is not entirely conforming, but the differences should be minor and are typically not observable. Fixes https://github.com/llvm/llvm-project/issues/75225
2024-01-16 19:14:33 +01:00
// Warning: This availability macro works differently than the other macros.
// The dylib part of print is not needed on Apple platforms. Therefore when
// the macro is not available the code calling the dylib is commented out.
// The macro _LIBCPP_AVAILABILITY_PRINT is not used.
[libc++][print] Adds ostream overloads. (#73262) Finishes implementation of - P2093R14 Formatted output - P2539R4 Should the output of std::print to a terminal be synchronized with the underlying stream? Differential Revision: https://reviews.llvm.org/D156609
2023-12-19 19:32:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_PRINT 0
# define _LIBCPP_AVAILABILITY_PRINT __attribute__((unavailable))
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format off
[libc++] Recategorize additional instantiations in the dylib as availability macros Adding additional instantiations to the dylib isn't actually an ABI break as long as programs targeting an older dylib don't start to depend on them. Making additional instantiations a matter of availability allows us to add them without an ABI break. Reviewed By: #libc, ldionne, Mordante Spies: arichardson, ldionne, Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D154796
2023-09-14 21:17:15 +02:00
# if (defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 120000) || \
(defined(__ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_IPHONE_OS_VERSION_MIN_REQUIRED__ < 150000) || \
(defined(__ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_TV_OS_VERSION_MIN_REQUIRED__ < 150000) || \
(defined(__ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__) && __ENVIRONMENT_WATCH_OS_VERSION_MIN_REQUIRED__ < 80000)
[libc++][NFC] Add a few clang-format annotations (#74352) This is in preparation for clang-formatting the whole code base. These annotations are required either to avoid clang-format bugs or because the manually formatted code is significantly more readable than the clang-formatted alternative. All in all, it seems like very few annotations are required, which means that clang-format is doing a very good job in most cases.
2023-12-04 15:17:31 -05:00
// clang-format on
[libc++][NFC] Refactor _LIBCPP_AVAILABILITY_HAS_* macros to always be defined (#71002) This makes the conditionals quite a bit simpler to understand, since it avoids double negatives and makes sure we have <__availability> included. For vendors which use availability macros, it also enforces that they check when specific features are introduced and define the macro for their platform appropriately.
2023-11-24 23:45:17 +01:00
# define _LIBCPP_AVAILABILITY_HAS_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1 0
# else
# define _LIBCPP_AVAILABILITY_HAS_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1 1
[libc++] Recategorize additional instantiations in the dylib as availability macros Adding additional instantiations to the dylib isn't actually an ABI break as long as programs targeting an older dylib don't start to depend on them. Making additional instantiations a matter of availability allows us to add them without an ABI break. Reviewed By: #libc, ldionne, Mordante Spies: arichardson, ldionne, Mordante, libcxx-commits Differential Revision: https://reviews.llvm.org/D154796
2023-09-14 21:17:15 +02:00
# 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-04 15:01:25 -05: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
[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`. Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits, smeenai Differential Revision: https://reviews.llvm.org/D143163
2023-02-02 11:47:01 +01:00
// Define availability attributes that depend on _LIBCPP_HAS_NO_EXCEPTIONS.
[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-04 15:01:25 -05:00
// Those are defined in terms of the availability attributes above, and
// should not be vendor-specific.
[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`. Reviewed By: ldionne, Mordante, #libc Spies: libcxx-commits, smeenai Differential Revision: https://reviews.llvm.org/D143163
2023-02-02 11:47:01 +01:00
#if defined(_LIBCPP_HAS_NO_EXCEPTIONS)
[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-04 15:01:25 -05:00
# 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_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-20 12:03:32 -04:00
#endif // _LIBCPP___AVAILABILITY
Reference in New Issue Copy Permalink