| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
The previous commit fixed most cases of %c formatting, but it
incorrectly prints times using the system's local time zone. This only
matters if the locale's %c format includes %Z, but some do.
To print a correct value for %Z we can set tm.tm_zone to either "UTC" or
the abbreviation passed to the formatter in the local-time-format-t
structure.
For local times with no info and for systems that don't support tm_zone
(which is new in POSIX.1-2024) we just set tm_isdst = -1 so that no zone
name is printed.
In theory, a locale's %c format could use %z which should print a +hhmm
offset from UTC. I'm unsure how to control that though. The new
tm_gmtoff field in combination with tm_isdst != -1 seems like it should
work, but using that without also setting tm_zone causes the system zone
to be used for %Z again. That means local_time_format(lt, nullptr, &off)
might work for a locale that uses %z but prints the wrong thing for %Z.
This commit doesn't set tm_gmtoff even if _M_offset_sec is provided for
a local-time-format-t value.
libstdc++-v3/ChangeLog:
PR libstdc++/117214
* configure.ac: Use AC_STRUCT_TIMEZONE.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Set
tm_isdst and tm_zone.
* testsuite/std/time/format/pr117214.cc: Check %c formatting of
zoned_time and local time.
|
|
Formatting a time point with %c was implemented by calling
std::vprint_to with format string constructed from locale's D_T_FMT
string, but in some locales this string contains strftime specifiers
which are not valid for chrono-specs, e.g. %l. So just use _M_locale_fmt
to avoid this problem.
libstdc++-v3/ChangeLog:
PR libstdc++/117214
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Use
_M_locale_fmt to format %c time point.
* testsuite/std/time/format/pr117214.cc: New test.
Signed-off-by: XU Kailiang <xu2k3l4@outlook.com>
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
|
|
When using std::time_put to format a chrono value, we should imbue the
formatting locale into the stream. This ensures that when
std::time_put::do_put uses a ctype or __timepunct facet from the locale,
it gets the correct facets.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_locale_fmt):
Imbue locale into ostringstream.
* testsuite/std/time/format/localized.cc: Check that correct
locale is used for call to time_put::put.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
Tomasz suggested replacing this constructor with just append_range(rg),
after using a delegating constructor so that the destructor will run if
append_range exits via an exception.
This is slightly less simple than his suggestion, because I want to
avoid the overhead of reserve's slow path and the ASan annotations.
Neither of those is needed for this constructor, because we have no
existing storage to reallocate and no unused capacity to tell ASan
about.
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (vector(from_range_t, Alloc)): Use
delegating constructor instead of RAII guards. Use append_range
for unsized input range case.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
libstdc++-v3/ChangeLog:
* src/c++23/std.compat.cc.in: Only export <stdbit.h> and
<stdckdint.h> contents for C++26 and later.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
Also export the tuple-like helpers from <complex>, and the
std::from_range_t and std::from_range tag.
libstdc++-v3/ChangeLog:
* src/c++23/std.cc.in (tuple_element, tuple_element_t)
(tuple_size, tuple_size_v, get): Export.
(ranges::cache_latest_view, views::cache_latest): Export.
(ranges::to_input_view, views::to_input): Export.
(from_range_t, from_range): Export.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
|
|
libstdc++-v3/ChangeLog:
* include/debug/unordered_map (unordered_map): Add from_range
constructors and deduction guides.
(unordered_multimap): Likewise.
* include/debug/unordered_set (unordered_set): Add from_range
constructors and deduction guides.
(unordered_multiset): Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
libstdc++-v3/ChangeLog:
* include/debug/map.h (map): Add from_range constructors and
deduction guides.
* include/debug/multimap.h (multimap): Likewise.
* include/debug/multiset.h (multiset): Likewise.
* include/debug/set.h (set): Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
Another IEE typo.
2025-03-20 Jakub Jelinek <jakub@redhat.com>
* testsuite/18_support/numeric_limits/traps.cc (main): Fix comment
typo.
|
|
|
|
The default is -std=gnu++17 now, not -std=gnu++14.
libstdc++-v3/ChangeLog:
* doc/xml/manual/test.xml: Fix default for -std option.
* doc/html/manual/test.html: Regenerate.
|
|
libstdc++-v3/ChangeLog:
* include/bits/locale_facets_nonio.tcc (time_put::do_put): Fix
typo in comment.
|
|
Now that std::set has support for __cpp_lib_ranges_to_container we can
activate a test using it in a fancy allocator pointer context.
libstdc++-v3/ChangeLog
* testsuite/23_containers/set/requirements/explicit_instantiation/alloc_ptr.cc:
Activate the template member tests involving __cpp_lib_ranges_to_container
support.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
Our <climits> ensures that LLONG_MIN, LLONG_MAX, and ULLONG_MAX are
defined even if the C library's <limits.h> doesn't define them. Our
<limits.h> then includes <climits>, which should mean that <limits.h>
and <climits> always define the same macros. However, we only install
our own version of <limits.h> for --enable-cheaders=c and not for the
default --enable-cheaders=c_global setting that everybody uses.
This means that if the C library's <limits.h> is not C++-aware, or if
the C library doesn't provide it and GCC's own gcc/glimits.h is used
instead, then <climits> defines the macros for long long types but
<limits.h> does not.
This causes the new 20_util/stdbit/1.cc test to fail for arm-non-eabi
because it uses gcc/glimits.h which is not C++-aware, only checking
__STDC_VERSION__ when deciding whether to declare the long long macros.
If gcc/glimits.h also checked __cplusplus it would be OK, and we would
not need our own <limits.h> to be installed.
This commit just changes the new test to use <climits> instead of
<limits.h>, but we should ensure that gcc/glimits.h is made to work
(i.e. define the long long macros) for C++, and/or install our own
<limits.h> for the --enable-cheaders=c_global configuration.
libstdc++-v3/ChangeLog:
* testsuite/20_util/stdbit/1.cc: Include <climits> instead of
<limits.h>.
|
|
This implements part of LWG4223 that enables deduction for maps types
(map, unordered_map, flat_map and non-unique equivalent) from
(from_range, rg, ...) arguments, where rg is range of tuple
or other pair-like.
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__detail::__range_key_type):
Replace RV::first_type with tuple_element_t<0, RV>.
(__detail::__range_mapped_type) Replace RV::second_type
with tuple_element_t<1, RV>.
* testsuite/23_containers/flat_map/1.cc: New tests.
* testsuite/23_containers/flat_multimap/1.cc: New tests.
* testsuite/23_containers/map/cons/from_range.cc: New tests.
* testsuite/23_containers/multimap/cons/from_range.cc: New tests.
* testsuite/23_containers/unordered_map/cons/from_range.cc: New tests.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc:
New tests.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
unordered containers.
This patch implements part of LWG2713 covering the from_range
constructors, which makes std::ranges::to<std::unordered_set>(alloc)
well-formed. Likewise for rest of unordered containers.
As this consturctors were added to v15, this has no impact
on code that compiled with previous versions.
libstdc++-v3/ChangeLog:
* include/bits/unordered_map.h
(unordered_map(from_range_t, _Rg&&, const allocator_type&))
(unordered_multimap(from_range_t, _Rg&&, const allocator_type&)):
Define.
* include/bits/unordered_set.h
(unordered_set(from_range_t, _Rg&&, const allocator_type&))
(unordered_multiset(from_range_t, _Rg&&, const allocator_type&)):
Define.
* testsuite/23_containers/unordered_map/cons/from_range.cc: New tests.
New tests.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc:
New tests.
* testsuite/23_containers/unordered_multiset/cons/from_range.cc:
New tests.
* testsuite/23_containers/unordered_set/cons/from_range.cc: New tests.
* testsuite/std/ranges/conv/1.cc: New tests.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
containers [PR119358]
ranges::distance may produce an integer-like class type
(ranges::__detail::__max_diff_type) that is only explicitly convertible to
other integer types, so the result needs to be casted to containers size_type.
PR libstdc++/119358
libstdc++-v3/ChangeLog:
* include/bits/unordered_map.h (unordered_multimap::insert_range):
Cast ranges::distance to size_type before passing to _M_rehash_insert.
* include/bits/unordered_set.h (unordered_multiset::insert_range):
Same as unordered_multimap::insert_range.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc:
New tests.
* testsuite/23_containers/unordered_multiset/cons/from_range.cc:
New tests.
|
|
|
|
This is another piece of P1206R7, adding new members to std::unordered_map
and std::unordered_multimap.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/unordered_map.h (unordered_map): Define from_range
constructors and insert_range member.
(unordered_multimap): Likewise.
* testsuite/23_containers/unordered_multimap/cons/from_range.cc:
New test.
* testsuite/23_containers/unordered_multimap/modifiers/insert_range.cc:
New test.
* testsuite/23_containers/unordered_map/cons/from_range.cc:
New test.
* testsuite/23_containers/unordered_map/modifiers/insert_range.cc:
New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This is another piece of P1206R7, adding new members to std::unordered_set
and std::unordered_multiset.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_M_rehash_insert)
(_M_insert_range_multi): Extracted rehashing for range insertion
to separate function.
* include/bits/unordered_set.h (unordered_set): Define from_range
constructors and insert_range member.
(unordered_multiset) Likewise.
* testsuite/23_containers/unordered_multiset/cons/from_range.cc:
New test.
* testsuite/23_containers/unordered_multiset/modifiers/insert_range.cc:
New test.
* testsuite/23_containers/unordered_set/cons/from_range.cc:
New test.
* testsuite/23_containers/unordered_set/modifiers/insert_range.cc:
New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This is another piece of P1206R7, adding new members to std::set
and std::multiset.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/stl_multiset.h: (inser_range)
(multiset(from_range_t, _Rg&&, const _Compare&, const _Alloc&))
(multiset(from_range_t, _Rg&&, const _Alloc&)): Define.
* include/bits/stl_set.h: (set(from_range_t, _Rg&&, const _Alloc&))
(set(from_range_t, _Rg&&, const _Compare&, const _Alloc&), insert_range):
Define.
* testsuite/23_containers/multiset/cons/from_range.cc: New test.
* testsuite/23_containers/multiset/modifiers/insert/insert_range.cc:
New test.
* testsuite/23_containers/set/cons/from_range.cc: New test.
* testsuite/23_containers/set/modifiers/insert/insert_range.cc:
New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This is another piece of P1206R7, adding new members to std::map
and std::multimap.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__detail::__range_to_alloc_type):
Define.
* include/bits/stl_multimap.h: (inser_range)
(multimap(from_range_t, _Rg&&, const _Compare&, const _Alloc&))
(multimap(from_range_t, _Rg&&, const _Alloc&)): Define.
* include/bits/stl_map.h: (map(from_range_t, _Rg&&, const _Alloc&)) i
(map(from_range_t, _Rg&&, const _Compare&, const _Alloc&), insert_range):
Define.
* testsuite/23_containers/multimap/cons/from_range.cc: New test.
* testsuite/23_containers/multimap/modifiers/insert/insert_range.cc: New test.
* testsuite/23_containers/map/cons/from_range.cc: New test.
* testsuite/23_containers/map/modifiers/insert/insert_range.cc: New test.
|
|
|
|
A missing 'constexpr' in the non-forward (and non-sized) branch of our
recently implemented vector from_range ctor was causing this valid example
to be rejected with a cryptic error.
PR libstdc++/119282
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (vector::vector(from_range_t)): Add
missing 'constexpr' to local class _Clear.
* testsuite/std/ranges/conv/1.cc (test_pr119282): New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
Add missing move_constructible && regular_invocable constrains on functor type,
and is_object on functor result type for invocations of views::zip_transform
without range arguments.
PR libstdc++/111138
libstdc++-v3/ChangeLog:
* include/std/ranges (_ZipTransform::operator()):
Create separate overload for calls with empty range pack,
and add move_constructible, regular_invocable and
is_object_v<invoke_result_t<...>>> constraints.
* testsuite/std/ranges/zip_transform/1.cc: New tests
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
We need '-fno-exceptions', '-fno-rtti', disable generation of PCH files, and
for nvptx twiddle some more knobs.
PR target/92713
PR target/101544
libstdc++-v3/
* config/cpu/nvptx/cpu_defines.h: New.
* config/cpu/nvptx/t-nvptx: Likewise.
* configure.host: Handle GCN, nvptx.
|
|
libstdc++-v3/ChangeLog:
* testsuite/23_containers/priority_queue/cons_from_range.cc:
Add `#include <algorithm>.
* testsuite/23_containers/priority_queue/members/push_range.cc:
Add `#include <algorithm>.
|
|
A std::weak_ptr<T[]> can be converted to a compatible
std::weak_ptr<U[]>. This is implemented by having suitable converting
constructors to std::weak_ptr which dispatch to the __weak_ptr base
class (implementation detail).
In __weak_ptr<T[]>, lock() is supposed to return a __shared_ptr<T[]>,
not a __shared_ptr<element_type> (that is, __shared_ptr<T>).
Unfortunately the return type of lock() and the type of the returned
__shared_ptr were mismatching and that was causing a compile error: when
converting a __weak_ptr<T[]> to a __weak_ptr<U[]> through __weak_ptr's
converting constructor, the code calls lock(), and that simply fails to
build.
Fix it by removing the usage of element_type inside lock(), and using
_Tp instead.
Note that std::weak_ptr::lock() itself was already correct; the one in
__weak_ptr was faulty (and that is the one called by __weak_ptr's
converting constructors).
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h (lock): Fixed a compile error
when calling lock() on a weak_ptr<T[]>, by removing an
erroneous usage of element_type from within lock().
* testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc:
Add more tests for array types.
* testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc:
Likewise.
* testsuite/20_util/shared_ptr/requirements/1.cc: New test.
* testsuite/20_util/weak_ptr/requirements/1.cc: New test.
|
|
|
|
The type tuple<tuple<any>> is clearly copy/move constructible, but for
reasons that are not yet completely understood checking this triggers
constraint recursion with our C++20 tuple implementation (but not the
C++17 implementation).
It turns out this recursion stems from considering the non-template
tuple(const _Elements&) constructor during the copy/move constructibility
check. Considering this constructor is ultimately redundant, since the
defaulted copy/move constructors are better matches.
GCC has a non-standard "perfect candidate" optimization[1] that causes
overload resolution to shortcut considering template candidates if we
find a (non-template) perfect candidate. So to work around this issue
(and as a general compile-time optimization) this patch turns the
problematic constructor into a template so that GCC doesn't consider it
when checking for copy/move constructibility of this tuple type.
Changing the template-ness of a constructor can affect overload
resolution (since template-ness is a tiebreaker) so there's a risk this
change could e.g. introduce overload resolution ambiguities. But the
original C++17 implementation has long defined this constructor as a
template (in order to constrain it etc), so doing the same thing in the
C++20 mode should naturally be quite safe.
The testcase still fails with Clang (in C++20 mode) since it doesn't
implement said optimization.
[1]: See r11-7287-g187d0d5871b1fa and
https://isocpp.org/files/papers/P3606R0.html
PR libstdc++/116440
libstdc++-v3/ChangeLog:
* include/std/tuple (tuple::tuple(const _Elements&...))
[C++20]: Turn into a template.
* testsuite/20_util/tuple/116440.C: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
This is another piece of P1206R7, adding new members to std::stack,
std::queue, and std::priority_queue.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/stl_queue.h (queue(from_range_t, _Rg&&))
(queue(from_range_t, _Rg&&, const _Alloc&), push_range):
Define.
(priority_queue(from_range_t, R&&, const Compare&))
(push_range): Define.
* include/bits/stl_stack.h (stack(from_range_t, R&&))
(stack(from_range_t, R&&, const Alloc&), push_range): Define.
* testsuite/util/testsuite_iterators.h (test_range_nocopy): Define.
* testsuite/23_containers/priority_queue/cons_from_range.cc: New test.
* testsuite/23_containers/priority_queue/members/push_range.cc: New test.
* testsuite/23_containers/queue/cons_from_range.cc: New test.
* testsuite/23_containers/queue/members/push_range.cc: New test.
* testsuite/23_containers/stack/cons_from_range.cc: New test.
* testsuite/23_containers/stack/members/push_range.cc: New test.
Co-authored-by: Tomasz Kamiński <tkaminsk@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This is the second part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N2683.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implementations, this change defines them in namespace __gnu_cxx and
then adds them to the global namespace.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add stdckdint.h.
* include/Makefile.in: Regenerate.
* src/c++23/std.compat.cc.in: Export <stdckdint.h> functions.
* include/c_compatibility/stdckdint.h: New file.
* testsuite/26_numerics/stdckdint/1.cc: New test.
* testsuite/26_numerics/stdckdint/2_neg.cc: New test.
Reviewed-by: Patrick Palka <ppalka@redhat.com>
|
|
This is the first part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N3022.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implementations, this change defines them in namespace __gnu_cxx and
then adds them to the global namespace.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add stdbit.h.
* include/Makefile.in: Regenerate.
* src/c++23/std.compat.cc.in: Export <stdbit.h> functions.
* include/c_compatibility/stdbit.h: New file.
* testsuite/20_util/stdbit/1.cc: New test.
* testsuite/20_util/stdbit/2_neg.cc: New test.
Reviewed-by: Patrick Palka <ppalka@redhat.com>
|
|
Unlike for span<X> and empty_view<X>, the range_reference_t of
ref_view<X> doesn't correspond to X. This patch fixes the ref_view
branch of views::as_const to correctly query its underlying range
type X.
PR libstdc++/119135
libstdc++-v3/ChangeLog:
* include/std/ranges: Include <utility>.
(views::__detail::__is_ref_view): Replace with ...
(views::__detail::__is_constable_ref_view): ... this.
(views::_AsConst::operator()): Replace bogus use of element_type
in the ref_view branch.
* testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend
test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite 'EXTRA_CXX_FLAGS'
(and instead append any additional '--enable-cxx-flags=[...]').
libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_CXX_FLAGS): Append to
'EXTRA_CXX_FLAGS' any additional flags.
* configure: Regenerate.
* configure.host: Document 'EXTRA_CFLAGS', 'EXTRA_CXX_FLAGS'.
|
|
basic_format_arg visitation [PR108053]
Implement visit_format_arg and basic_format_arg::visit function,
in terms of _M_visit_user member functions, that wraps any type
stored inside basic_format_arg, that is not specified in the standard,
into the handle. This affects __int128, unsigned __int128,
PowerPC specific __ieee128 and __ibm128, and _Float128 for architectures
where long double is not 128bits.
The bfloat16, _Float16, _Float32, _Float32, and _Float128 for
128bits long double are not are not addressed, as they
are transformed into a standard floating point types.
For internal purposes __format::__visit_format_arg function is
used, that provides an unmodified access to stored object.
PR libstdc++/108053
libstdc++-v3/ChangeLog:
* include/std/format (basic_format_arg::_M_visit_user):
Helper function for wrapping extension types into handle.
(visit_format_arg): Call `_M_visit_user` instead of `_M_visit`.
(basic_format_arg::visit): As above.
(__format::__visit_format_arg): Provides direct access to
values stored in basic_format_arg.
(__format::__int_from_arg): Use __format::__visit_format_arg
instead of std::visit_format_arg.
(_Formatting_scanner::_M_format_arg): As above.
(_Checking_scanner::__do_vformat_to): As above.
* testsuite/std/format/arguments/args.cc: New tests.
* testsuite/std/format/string.cc: Test for using __int128
as width/precision.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
|
|
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges_to_input): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (ranges::to_input_view): Define for C++26.
(views::__detail::__can_to_input): Likewise.
(views::_ToInput, views::to_input): Likewise.
* testsuite/std/ranges/adaptors/to_input/1.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
In r15-5832-g91f4550e1700b7 std::monostate was moved to its own header,
which means that <format> no longer needs to include all of <variant>.
libstdc++-v3/ChangeLog:
* include/std/format: Include <bits/monostate.h> instead of
<variant>.
|
|
This change makes the check_dynamic_spec precondition checks slightly
faster to compile, and avoids those checks entirely for the common cases
of calling check_dynamic_spec_integral or check_dynamic_spec_string.
Instead of checking for unique types by keeping counts in an array and
looping over that array, we can just keep a sum of how many valid types
are present, and check that it equals the total number of types in the
pack.
The diagnostic is slightly worse now, because there's only a single
"invalid template argument types" string that appears in the output,
where previously we had either "non-unique template argument type" or
"disallowed template argument type", depending on the failure mode.
Given that most users will never use this function directly, and
probably won't use invalid types anyway, the inferior diagnostic seems
acceptable.
libstdc++-v3/ChangeLog:
* include/std/format (basic_format_parse_context::__once): New
variable template.
(basic_format_parse_context::__valid_types_for_check_dynamic_spec):
New function template for checking argument types.
(basic_format_parse_context::__check_dynamic_spec): New function
template to implement the common check_dynamic_spec logic.
(basic_format_parse_context::check_dynamic_spec_integral): Call
__check_dynamic_spec instead of check_dynamic_spec.
(basic_format_parse_context::check_dynamic_spec_string):
Likewise. Use _CharT instead of char_type consistently.
(basic_format_parse_context::check_dynamic_spec): Use
__valid_types_for_check_dynamic_spec for precondition checks and
call __check_dynamic_spec for checking the arg id.
* testsuite/std/format/parse_ctx_neg.cc: Adjust expected errors.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates:
precondition for std::packaged_task::packaged_task(F&&) to match what
the implementation actually requires. We already gave a diagnostic in
the right cases as required by the issue resolution, so strictly
speaking we don't need to do anything. But the current diagnostic comes
from inside the implementation of std::__invoke_r and could be more
user-friendly.
For C++17 (when std::is_invocable_r_v is available) add a static_assert
to the constructor, so the error is clear:
.../include/c++/15.0.1/future: In instantiation of 'std::packaged_task<_Res(_ArgTypes ...)>::packaged_task(_Fn&&) [with _Fn = const F&; <template-parameter-2-2> = void; _Res = void; _ArgTypes = {}]':
lwg4154_neg.cc:15:31: required from here
15 | std::packaged_task<void()> p(f); // { dg-error "here" "" { target c++17 } }
| ^
.../include/c++/15.0.1/future:1575:25: error: static assertion failed
1575 | static_assert(is_invocable_r_v<_Res, decay_t<_Fn>&, _ArgTypes...>);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also add a test to confirm we get a diagnostic as the standard requires.
libstdc++-v3/ChangeLog:
* include/std/future (packaged_task::packaged_task(F&&)): Add
static_assert.
* testsuite/30_threads/packaged_task/cons/dangling_ref.cc: Add
dg-error for new static assertion.
* testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc: New
test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
Import the new 2025a tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).
libstdc++-v3/ChangeLog:
* include/std/chrono (__detail::__get_leap_second_info): Update
expiry date for leap seconds list.
* src/c++20/tzdata.zi: Import new file from 2025a release.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds)
Update expiry date for leap seconds list.
|
|
Floating points types _Float16, _Float32, _Float64, and bfloat16,
can be formatted only if std::to_chars overloads for such types
were provided. Currently this is only the case for architectures
where float and double are 32-bits and 64-bits IEEE floating points types.
This patch updates the preprocessing checks for formatters
for above types to check _GLIBCXX_FLOAT_IS_IEEE_BINARY32
and _GLIBCXX_DOUBLE_IS_IEEE_BINARY64. Making them non-formattable
on non-IEEE architectures.
Remove a potential UB, where we could produce basic_format_arg
with _M_type set to _Arg_fp32 or _Arg_fp64, that was later not
handled by `_M_visit`.
libstdc++-v3/ChangeLog:
* include/std/format (formatter<_Float16, _CharT>): Define only if
_GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is defined.
(formatter<_Float16, _CharT>): As above.
(formatter<__gnu_cxx::__bfloat16_t, _CharT>): As above.
(formatter<_Float64, _CharT>): Define only if
_GLIBCXX_DOUBLE_IS_IEEE_BINARY64 is defined.
(basic_format_arg::_S_to_arg_type): Normalize _Float32 and _Float64
only to float and double respectivelly.
(basic_format_arg::_S_to_enum): Remove handling of _Float32 and _Float64.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
libstdc++-v3/ChangeLog:
* doc/xml/manual/strings.xml: Tweak formatting. Add example
using lambda.
* doc/html/manual/strings.html: Regenerate.
|
|
LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to
dereference a std::unique_ptr if that would return a dangling reference.
That can happen with a custom pointer type and a const-qualified
element_type, such that std::add_lvalue_reference_t<element_type> is a
reference-to-const that could bind to a short-lived temporary.
In C++26 the compiler diagnoses this as an error anyway:
bits/unique_ptr.h:457:16: error: returning reference to temporary [-Wreturn-local-addr]
But that can be disabled with -Wno-return-local-addr so the
static_assert ensures it is enforced consistently.
libstdc++-v3/ChangeLog:
* include/bits/unique_ptr.h (unique_ptr::operator*): Add
static_assert to check for dangling reference, as per LWG 4148.
* testsuite/20_util/unique_ptr/lwg4148.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
LWG 4112 (approved in Wrocław, November 2024) changes the has-arrow
helper to require operator-> to be valid on a const-qualified lvalue.
This affects the constraints for filter_view::_Iterator::operator-> and
join_view::_Iterator::operator-> so that they can only be used if the
underlying iterator supports operator-> on const.
The change also adds semantic (i.e. not checkable and not enforced)
requirements that operator-> must have the same semantics whether called
on a const or non-const value, and on an lvalue or rvalue (due to the
implicit expression variation rules in [concepts.equality]).
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (ranges::_detail::__has_arrow):
Require operator->() to be valid on const-qualified type, as per
LWG 4112.
* testsuite/std/ranges/adaptors/lwg4112.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
LWG 4142 (approved in Wrocław, November 2024) made it ill-formed to call
basic_format_parse_context::check_dynamic_spec with an empty template
argument list.
This adds a static_assert to enforce that, and adjusts the tests.
libstdc++-v3/ChangeLog:
* include/std/format
(basic_format_parse_context::check_dynamic_spec): Require a
non-empty parameter pack, as per LWG 4142.
* testsuite/std/format/parse_ctx.cc: Remove call of
check_dynamic_spec with empty template argument list.
* testsuite/std/format/parse_ctx_neg.cc: Add dg-error to call of
check_dynamic_spec with empty template argument list.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
|
