mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-29 10:46:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/libcxx/include/__format/formatter_integer.h

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

96 lines
3.9 KiB
C
Raw Normal View History

[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01: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___FORMAT_FORMATTER_INTEGER_H
#define _LIBCPP___FORMAT_FORMATTER_INTEGER_H
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
#include <__concepts/arithmetic.h>
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
#include <__config>
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
#include <__format/concepts.h>
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
#include <__format/format_parse_context.h>
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
#include <__format/formatter.h>
#include <__format/formatter_integral.h>
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
#include <__format/formatter_output.h>
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
#include <__format/parser_std_format_spec.h>
[NFC][libc++] Use a better type_trait to show the intention.
2023-06-29 19:56:28 +02:00
#include <__type_traits/is_void.h>
[libc++] Granularize some more type_traits Reviewed By: ldionne, #libc Spies: libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D128948
2022-07-24 16:03:12 +02:00
#include <__type_traits/make_32_64_or_128_bit.h>
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
#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++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
#endif
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
_LIBCPP_BEGIN_NAMESPACE_STD
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962
2023-02-14 00:56:09 +01:00
#if _LIBCPP_STD_VER >= 20
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS __formatter_integer {
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
public:
[NFC][libc++][format] Uses uniform member signatures. The newer formatters for (tuple, vector<bool>::reference) specify the formatter's parse and format member function. This signature is slightly different from the signature for existing formatters. Adapt the existing formatters to the new style. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D150034
2023-05-06 13:28:46 +02:00
template <class _ParseContext>
_LIBCPP_HIDE_FROM_ABI constexpr typename _ParseContext::iterator parse(_ParseContext& __ctx) {
typename _ParseContext::iterator __result = __parser_.__parse(__ctx, __format_spec::__fields_integral);
[libc++][format] Improves run-time diagnostics. After parsing a std-format-spec it's validated, depending on the type used some format options are not allowed. This improves the error messages in the exceptions thrown upon failure. Depends on D155364 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D155366
2023-06-04 21:32:10 +02:00
__format_spec::__process_parsed_integer(__parser_, "an integer");
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
return __result;
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
}
[NFC][libc++][format] Uses uniform member signatures. The newer formatters for (tuple, vector<bool>::reference) specify the formatter's parse and format member function. This signature is slightly different from the signature for existing formatters. Adapt the existing formatters to the new style. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D150034
2023-05-06 13:28:46 +02:00
template <integral _Tp, class _FormatContext>
_LIBCPP_HIDE_FROM_ABI typename _FormatContext::iterator format(_Tp __value, _FormatContext& __ctx) const {
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
__format_spec::__parsed_specifications<_CharT> __specs = __parser_.__get_parsed_std_specifications(__ctx);
if (__specs.__std_.__type_ == __format_spec::__type::__char)
return __formatter::__format_char(__value, __ctx.out(), __specs);
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
using _Type = __make_32_64_or_128_bit_t<_Tp>;
[NFC][libc++] Use a better type_trait to show the intention.
2023-06-29 19:56:28 +02:00
static_assert(!is_void<_Type>::value, "unsupported integral type used in __formatter_integer::__format");
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
// Reduce the number of instantiation of the integer formatter
return __formatter::__format_integer(static_cast<_Type>(__value), __ctx, __specs);
}
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
__format_spec::__parser<_CharT> __parser_;
};
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
// Signed integral types.
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<signed char, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<short, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<int, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<long, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<long long, _CharT> : public __formatter_integer<_CharT> {};
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
# ifndef _LIBCPP_HAS_NO_INT128
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<__int128_t, _CharT> : public __formatter_integer<_CharT> {};
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
# endif
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
// Unsigned integral types.
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<unsigned char, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<unsigned short, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<unsigned, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<unsigned long, _CharT> : public __formatter_integer<_CharT> {};
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<unsigned long long, _CharT> : public __formatter_integer<_CharT> {};
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
# ifndef _LIBCPP_HAS_NO_INT128
[NFC][libc++][format] Renames __char_type concept. Move the concept to the concepts header and uses a name in the style of P2286. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D131176
2022-08-04 17:54:20 +02:00
template <__fmt_char_type _CharT>
[libc++] Remove availability markup for std::format std::format is currently experimental, so there is technically no deployment target requirement for it (since the only symbols required for it are in `libc++experimental.a`). However, some parts of std::format depend indirectly on the floating point std::to_chars implementation, which does have deployment target requirements. This patch removes all the availability format for std::format and updates the XFAILs in the tests to properly explain why they fail on old deployment targets, when they do. It also changes a couple of tests to avoid depending on floating-point std::to_chars when it isn't fundamental to the test. Finally, some tests are marked as XFAIL but I added a comment saying TODO FMT This test should not require std::to_chars(floating-point) These tests do not fundamentally depend on floating-point std::to_chars, however they end up failing because calling std::format even without a floating-point argument to format will end up requiring floating-point std::to_chars. I believe this is an implementation artifact that could be avoided in all cases where we know the format string at compile-time. In the tests, I added the TODO comment only to the places where we could do better and actually avoid relying on floating-point std::to_chars because we know the format string at compile-time. Differential Revision: https://reviews.llvm.org/D134598
2023-03-16 13:09:44 -04:00
struct _LIBCPP_TEMPLATE_VIS formatter<__uint128_t, _CharT> : public __formatter_integer<_CharT> {};
[libc++][format] Improve integral formatters. This changes the implementation of the formatter. Instead of inheriting from a specialized parser all formatters will use the same generic parser. This reduces the binary size. The new parser contains some additional fields only used in the chrono formatting. Since this doesn't change the size of the parser the fields are in the generic parser. The parser is designed to fit in 128-bit, making it cheap to pass by value. The new format function is a const member function. This isn't required by the Standard yet, but it will be after LWG-3636 is accepted. Additionally P2286 adds a formattable concept which requires the member function to be const qualified in C++23. This paper is likely to be accepted in the 2022 July plenary. This is based on D125606. That commit did the groundwork and did similar changes for the string formatters. Depends on D125606 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128139
2021-12-28 18:48:04 +01:00
# endif
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
[libc++][NFC] Replace _LIBCPP_STD_VER > x with _LIBCPP_STD_VER >= x This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed. Reviewed By: ldionne, var-const, #libc Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei Differential Revision: https://reviews.llvm.org/D143962
2023-02-14 00:56:09 +01:00
#endif //_LIBCPP_STD_VER >= 20
[libc++][format] Adds integer formatter. Implements the formatter for all fundamental integer types (except `char`, `wchar_t`, and `bool`). [format.formatter.spec]/2.3 For each charT, for each cv-unqualified arithmetic type ArithmeticT other than char, wchar_t, char8_t, char16_t, or char32_t, a specialization ``` template<> struct formatter<ArithmeticT, charT>; ``` This removes the stub implemented in D96664. As an extension it adds partial support for 128-bit integer types. Implements parts of: - P0645 Text Formatting - P1652 Printf corner cases in std::format Completes: - LWG-3248 #b, #B, #o, #x, and #X presentation types misformat negative numbers Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103433
2020-12-14 17:39:15 +01:00
_LIBCPP_END_NAMESPACE_STD
#endif // _LIBCPP___FORMAT_FORMATTER_INTEGER_H
Reference in New Issue Copy Permalink