| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
flat_set::emplace (and flat_multiset's) currently unconditionally
constructs an object outside of the container, but if we're passed
a value_type object we can and should avoid that.
PR libstdc++/119620
libstdc++-v3/ChangeLog:
* include/std/flat_set (_Flat_set_impl::_M_try_emplace): Split
out into two overloads, one taking at least one argument and one
taking zero arguments. Turn __k into an auto&& reference bound
to __arg if it's already a value_type and otherwise bound to a
lifetime-extended value_type temporary.
* testsuite/23_containers/flat_multiset/1.cc (test08): New test.
* testsuite/23_containers/flat_set/1.cc (test08): New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
[PR101587]
In r15-8980-gf4b6acfc36fb1f I introduced a new function object for
finding the smaller of two distances. In bugzilla Hewill Kang pointed
out that we still need to explicitly convert the result back to the
right difference type, because the result might be an integer-like class
type that doesn't convert to an integral type explicitly.
Rather than doing that conversion in the __mindist function object, I
think it's simpler to remove it again and just do a comparison and
assignment. We always want the result to have a specific type, so we can
just check if the value of the other type is smaller, and then convert
that to the other type if so.
libstdc++-v3/ChangeLog:
PR libstdc++/101587
* include/bits/ranges_uninitialized.h (__detail::__mindist):
Remove.
(ranges::uninitialized_copy, ranges::uninitialized_copy_n)
(ranges::uninitialized_move, ranges::uninitialized_move_n): Use
comparison and assignment instead of __mindist.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
Check with ranges that use integer-like class type for
difference type.
* testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.
Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com>
Reviewed-by: Hewill Kang <hewillk@gmail.com>
|
|
This patch implement formatter for vector<bool>::reference which
is part of P2286R8.
To indicate partial support we define __glibcxx_format_ranges macro
value 1, without defining __cpp_lib_format_ranges.
To avoid including the whole content of the <format> header, we
introduce new bits/formatfwd.h forward declares classes required
for newly introduce formatter.
The signatures of the user-facing parse and format method of the provided
formatters deviate from the standard by constraining types of params:
* _Bit_reference instead T satisfying is-vector-bool-reference<T>
* _CharT is constrained __formatter::__char
* basic_format_parse_context<_CharT> for parse argument
* basic_format_context<_Out, _CharT> for format second argument
The standard specifies last three of above as unconstrained types, which leads
to formattable<vector<bool>::reference, char32_t> (and any other type as char)
being true.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add bits/formatfwd.h.
* include/Makefile.in: Add bits/formatfwd.h.
* include/bits/version.def: Define __glibcxx_format_ranges without
corresponding std name.
* include/bits/version.h: Regenerate.
* include/std/format (basic_format_context, __format::__char):
Move declartions to bits/formatfwd.h.
(formatter<_Tp, _CharT>): Remove default argument for _CharT
parameter, now specified in forward declaration in bits/formatfwd.h.
* include/std/vector (formatter<_Bit_reference, _CharT>): Define.
* include/bits/formatfwd.h: New file with forward declarations
for bits of std/format.
* testsuite/23_containers/vector/bool/format.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
We can use the __glibcxx_string_view macro to guard the uses of
std::string_view in <string>, instead of just checking the value of
__cplusplus. It makes no practical difference because
__glibcxx_string_view is defined for C++17 and up, but it makes it clear
to readers that the lines guarded by that macro are features that depend
on string_view.
We could be more precise and check __glibcxx_string_view >= 201606L
which is the value for the P0254R2 paper that integrated
std::string_view with std::string, but I think just checking for the
macro being defined is clear enough.
We can also check __glibcxx_variant for the _Never_valueless_alt partial
specialization.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Check __glibcxx_string_view and
__glibcxx_variant instead of __cplusplus >= 2017L.
* include/bits/cow_string.h: Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
libstdc++-v3/ChangeLog:
* include/bits/basic_string.tcc: Fix whitespace.
|
|
This is useful to provide libstdc++-internal-only macros.
libstdc++-v3/ChangeLog:
* include/bits/version.tpl: Implement no_stdname.
* include/bits/version.def: Document no_stdname.
|
|
[PR119593]
This patch corrects handling of UTF-32LE and UTF32-BE in
__unicode::__literal_encoding_is_unicode<_CharT>, so they are
recognized as unicode and functions produces correct result for wchar_t.
Use `__unicode::__field_width` to compute the estimated witdh
of the charcter for unicode wide encoding.
PR libstdc++/119593
libstdc++-v3/ChangeLog:
* include/bits/unicode.h
(__unicode::__literal_encoding_is_unicode<_CharT>):
Corrected handing for UTF-16 and UTF-32 with "LE" or "BE" suffix.
* include/std/format (__formatter_str::_S_character_width):
Define.
(__formatter_str::_S_character_width): Updated passed char
length.
* testsuite/std/format/functions/format.cc: Test for wchar_t.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This is yet another false positive warning fix. This time the compiler
can't prove that when the vector has sufficient excess capacity to
append new elements, the pointer to the existing storage is not null.
libstdc++-v3/ChangeLog:
PR libstdc++/114945
* include/bits/vector.tcc (vector::_M_default_append): Add
unreachable condition so the compiler knows that _M_finish is
not null.
* testsuite/23_containers/vector/capacity/114945.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
In this case, we need to tell the compiler that the current size is not
larger than the new size so that all the existing elements can be copied
to the new storage. This avoids bogus warnings about overflowing the new
storage when the compiler can't tell that that cannot happen.
We might as well also hoist the loads of begin() and end() before the
allocation too. All callers will have loaded at least begin() before
calling _M_reallocate.
libstdc++-v3/ChangeLog:
PR libstdc++/110498
* include/bits/vector.tcc (vector<bool, A>::_M_reallocate):
Hoist loads of begin() and end() before allocation and use them
to state an unreachable condition.
* testsuite/23_containers/vector/bool/capacity/110498.cc: New
test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
As in r13-4393-gcca06f0d6d76b0 and a few other commits, we can avoid
bogus warnings in std::vector<bool> by hoisting some loads to before the
allocation that calls operator new. This means that the compiler has
enough info to remove the dead branches that trigger bogus warnings.
On trunk this is only needed with -fno-assume-sane-operators-new-delete
but it will help on the branches where that option doesn't exist.
libstdc++-v3/ChangeLog:
PR libstdc++/114758
* include/bits/vector.tcc (vector<bool, A>::_M_fill_insert):
Hoist loads of begin() and end() before allocation.
* testsuite/23_containers/vector/bool/capacity/114758.cc: New
test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
In r15-8491-g778c28c70f8573 I added a use of the Autoconf macro
AC_STRUCT_TIMEZONE, but that requires a link-test for the global tzname
object if tm.tm_zone isn't supported. That link-test isn't allowed for
cross-compilation, so bootstrap fails if tm.tm_zone isn't supported.
Since libstdc++ only cares about tm.tm_zone and won't use tzname anyway,
we don't need the link-test. Replace AC_STRUCT_TIMEZONE with a custom
macro that only checks for tm.tm_zone. We can improve on the Autoconf
macro by checking it's a suitable type, which isn't actually checked by
AC_STRUCT_TIMEZONE.
libstdc++-v3/ChangeLog:
PR libstdc++/119550
* acinclude.m4 (GLIBCXX_STRUCT_TM_TM_ZONE): New macro.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_STRUCT_TM_TM_ZONE.
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Check
_GLIBCXX_USE_STRUCT_TM_TM_ZONE instead of
_GLIBCXX_HAVE_STRUCT_TM_TM_ZONE.
|
|
The boolean-testable requirements don't require the type to be copyable,
so we need to convert to bool before it might need to be copied.
libstdc++-v3/ChangeLog:
PR libstdc++/119545
* include/std/tuple (operator==): Convert comparison results to
bool.
* testsuite/20_util/tuple/comparison_operators/119545.cc: New
test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
The formatters for chrono types defined the parse/format methods
as accepting unconstrained types, this in combination with lack
of constrain on _CharT lead to them falsely satisfying formattable
requirements for any type used as character.
This patch adjust the fromatter<T, CharT>::parse signature to:
constexpr typename basic_format_parse_context<_CharT>::iterator
parse(basic_format_parse_context<_CharT>& __pc);
And formatter<T, CharT>::format to:
template<typename _Out>
typename basic_format_context<_Out, _CharT>::iterator
format(const T& __t,
basic_format_context<_Out, _CharT>& __fc) const;
Furthermore we _CharT with __format::__char (char or wchar_t),
PR libstdc++/119517
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (formatter):
Add __format::__char for _CharT and adjust parse and format
method signatures.
* testsuite/std/time/format/pr119517.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
this patch improves code generation on string constructors. We currently have
_M_construct which takes as a parameter two iterators (begin/end pointers to
other string) and produces new string. This patch adds special case of
constructor where instead of begining/end pointers we readily know the string
size and also special case when we know that source is 0 terminated. This
happens commonly when producing stirng copies. Moreover currently ipa-prop is
not able to propagate information that beg-end is known constant (copied string
size) which makes it impossible for inliner to spot the common case where
string size is known to be shorter than 15 bytes and fits in local buffer.
Finally I made new constructor inline. Because it is explicitely instantiated
without C++20 constexpr we do not produce implicit instantiation (as required
by standard) which prevents inlining, ipa-modref and any other IPA analysis to
happen. I think we need to make many of the other functions inline, since
optimization accross string manipulation is quite important. There is PR94960
to track this issue.
Bootstrapped/regtested x86_64-linux, OK?
libstdc++-v3/ChangeLog:
PR tree-optimization/103827
PR tree-optimization/80331
PR tree-optimization/87502
* config/abi/pre/gnu.ver: Add version for _M_construct<bool>
* include/bits/basic_string.h: (basic_string::_M_construct<bool>): Declare.
(basic_string constructors): Use it.
* include/bits/basic_string.tcc: (basic_string::_M_construct<bool>): New template.
* src/c++11/string-inst.cc: Instantated S::_M_construct<bool>.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/pr80331.C: New test.
* g++.dg/tree-ssa/pr87502.C: New test.
|
|
Because ranges can have any signed integer-like type as difference_type,
it's not valid to use std::min(diff1, diff2). Instead of calling
std::min with an explicit template argument, this adds a new __mindist
helper that determines the common type and uses that with std::min.
libstdc++-v3/ChangeLog:
PR libstdc++/101587
* include/bits/ranges_uninitialized.h (__detail::__mindist):
New function object.
(ranges::uninitialized_copy, ranges::uninitialized_copy_n)
(ranges::uninitialized_move, ranges::uninitialized_move_n): Use
__mindist instead of std::min.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
Check ranges with difference difference types.
* testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.
|
|
Iain reported that he's seeing this on Darwin:
include/bits/chrono_io.h:914: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
This is because the BSD definition ot tm::tm_zone is a char* (and has
been since 1987) rather than const char* as in Glibc and POSIX.1-2024.
We can fix it by using const_cast<char*> when setting the tm_zone
member. This should be safe because libc doesn't actually write anything
to tm_zone; it's only non-const because the BSD definition predates the
addition of the const keyword to C.
For targets where it's a const char* the cast won't matter because it
will be converted back to const char* on assignment anyway.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_c): Use
const_cast when setting tm.tm_zone.
Reviewed-by: Iain Sandoe <iain@sandoe.co.uk>
|
|
Now that the algorithms have been merged we can advertise full support
for P2562R1. This effectively reverts r15-8933-ga264c270fde292.
libstdc++-v3/ChangeLog:
PR libstdc++/119488
* include/bits/version.def (constexpr_algorithms): Bump
the feature-testing macro.
* include/bits/version.h: Regenerate.
* testsuite/25_algorithms/cpp_lib_constexpr.cc: Test the
bumped value for the feature-testing macro.
|
|
This completes the implementation of P2562R1 for C++26.
Unlike the other constexpr algorithms of the same family,
stable_partition does not have a constexpr-friendly version "ready to
use" during constant evaluation. In fact, it is not even available on
freestanding, because it always allocates a temporary memory buffer.
This commit implements the simplest possible strategy: during constant
evaluation allocate a buffer of length 1 on the stack, and use that as
a working area.
libstdc++-v3/ChangeLog:
* include/bits/algorithmfwd.h (stable_partition): Mark it
as constexpr for C++26.
* include/bits/ranges_algo.h (__stable_partition_fn): Likewise.
* include/bits/stl_algo.h (stable_partition): Mark it as
constexpr for C++26; during constant evaluation use a new
codepath where a temporary buffer of 1 element is used.
* testsuite/25_algorithms/headers/algorithm/synopsis.cc
(stable_partition): Add constexpr.
* testsuite/25_algorithms/stable_partition/constexpr.cc: New test.
|
|
This commit adds support for constexpr inplace_merge, added by P2562R1
for C++26. The implementation strategy is the same as for constexpr
stable_sort: use if consteval to detect if we're in constant evaluation,
and dispatch to a suitable path (same one as freestanding).
libstdc++-v3/ChangeLog:
* include/bits/algorithmfwd.h (inplace_merge): Mark it as
constexpr for C++26.
* include/bits/ranges_algo.h (__inplace_merge_fn): Likewise.
* include/bits/stl_algo.h (inplace_merge): Mark it as constexpr;
during constant evaluation, dispatch to the non-allocating
codepath.
* testsuite/25_algorithms/headers/algorithm/synopsis.cc
(inplace_merge): Add constexpr.
* testsuite/25_algorithms/inplace_merge/constexpr.cc: New test.
|
|
The result of std::move (or a cast to an rvalue reference) on a function
reference is always an lvalue. Because std::ranges::iter_move was using
the type std::remove_reference_t<X>&& as the result of std::move, it was
giving the wrong type for function references. Use a decltype-specifier
with declval<remove_reference_t<X>>() instead of just using the
remove_reference_t<X>&& type directly. This gives the right result,
while still avoiding the cost of doing overload resolution for
std::move.
libstdc++-v3/ChangeLog:
PR libstdc++/119469
* include/bits/iterator_concepts.h (_IterMove::__result): Use
decltype-specifier instead of an explicit type.
* testsuite/24_iterators/customization_points/iter_move.cc:
Check results for function references.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
P2562R1 ("constexpr Stable Sorting") adds constexpr to stable_sort,
stable_partition and inplace_merge. However only the first is already
implemented in libstdc++, so we shouldn't bump the feature-testing
macro to the bumped C++26 value. This commit sets it to one less
than the final value.
Amends r15-7708-gff43f9853d3b10.
libstdc++-v3/ChangeLog:
* include/bits/version.def (constexpr_algorithms): Change
the value of the feature-testing macro.
* include/bits/version.h: Regenerate.
* testsuite/25_algorithms/cpp_lib_constexpr.cc: Amend the
check of the feature-testing macro.
|
|
[PR119415]
As pointed out by Hewill Kang (reporter) in the issue, checking if iterator
of the incoming range satisfies __cpp17_input_iterator, may still lead
to hard errors inside of insert_range for iterators that satisfies
that concept, but specialize iterator_traits without iterator_category
typedef (std::common_iterator specialize iterator_traits without
iterator_category in some cases).
To address that we instead check if the iterator_traits<It>::iterator_category
is present and denote at least input_iterator_tag, using existing __has_input_iter_cat.
PR libstdc++/119415
libstdc++-v3/ChangeLog:
* include/std/flat_set (_Flat_set_impl:insert_range):
Replace __detail::__cpp17_input_iterator with __has_input_iter_cat.
* testsuite/23_containers/flat_multiset/1.cc: New tests
* testsuite/23_containers/flat_set/1.cc: New tests
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This is another piece of P1206R7, adding from_range constructor, append_range,
prepend_range, insert_range, and assign_range members to std::deque.
For append_front of input non-sized range, we are emplacing element at the front and
then reverse inserted elements. This does not existing elements, and properly handle
aliasing ranges.
For insert_range, the handling of insertion in the middle of input-only ranges
that are sized could be optimized, we still insert nodes one-by-one in such case.
For forward and stronger ranges, we reduce them to common_range case, by computing
the iterator when computing the distance. This is slightly suboptimal, as it require
range to be iterated for non-common forward ranges that are sized, but reduces
number of instantiations.
This patch extract _M_range_prepend, _M_range_append helper functions that accepts
(iterator, sentinel) pair. This all used in all standard modes.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/deque.tcc (deque::prepend_range, deque::append_range)
(deque::insert_range, __advance_dist): Define.
(deque::_M_range_prepend, deque::_M_range_append):
Extract from _M_range_insert_aux for _ForwardIterator(s).
* include/bits/stl_deque.h (deque::assign_range): Define.
(deque::prepend_range, deque::append_range, deque::insert_range):
Declare.
(deque(from_range_t, _Rg&&, const allocator_type&)): Define constructor
and deduction guide.
* include/debug/deque (deque::prepend_range, deque::append_range)
(deque::assign_range): Define.
(deque(from_range_t, _Rg&&, const allocator_type&)): Define constructor
and deduction guide.
* testsuite/23_containers/deque/cons/from_range.cc: New test.
* testsuite/23_containers/deque/modifiers/append_range.cc: New test.
* testsuite/23_containers/deque/modifiers/assign/assign_range.cc:
New test.
* testsuite/23_containers/deque/modifiers/prepend_range.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
LWG 4229 points out that the std::ranges::to wording refers to class
types, but I added an assertion using std::is_class_v which only allows
non-union class types. LWG consensus is that unions should be allowed,
so this additionally uses std::is_union_v.
libstdc++-v3/ChangeLog:
* include/std/ranges (ranges::to): Allow unions as well as
non-union class types.
* testsuite/std/ranges/conv/lwg4229.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
LWG 3291 make std::ranges::iota_view's iterator have input_iterator_tag
as its iterator_category, even though it satisfies the C++20
std::forward_iterator concept. This means that the traditional
std::vector::vector(InputIterator, InputIterator) constructor treats
iota_view iterators as input iterators, because it only understands the
C++17 iterator requirements, not the C++20 iterator concepts. This
results in a loop that calls emplace_back for each individual element of
the iota_view, requiring the vector to reallocate repeatedly as the
values are inserted. This makes it unnecessarily slow to construct a
vector from an iota_view.
This change adds a new _M_range_initialize_n function for initializing a
vector from a range (which doesn't have to be common) and a size. This
new function can be used by vector(InputIterator, InputIterator) and
vector(from_range_t, R&&) when std::ranges::distance can be used to get
the size. It can also be used by the _M_range_initialize overload that
gets the size for a Cpp17ForwardIterator pair using std::distance, and
by the vector(initializer_list) constructor.
With this new function constructing a std::vector from iota_view does
a single allocation of the correct size and so doesn't need to
reallocate in a loop.
Previously the _M_range_initialize overload for Cpp17ForwardIterator was
using a local RAII _Guard_alloc object to own the storage, but that was
redundant. The _Vector_base can own the storage right away, and its
destructor will deallocate it if _M_range_initialize exits via an
exception.
libstdc++-v3/ChangeLog:
PR libstdc++/108487
* include/bits/stl_vector.h (vector(initializer_list)): Call
_M_range_initialize_n instead of _M_range_initialize.
(vector(InputIterator, InputIterator)): Use _M_range_initialize_n
for C++20 sized sentinels and forward iterators.
(vector(from_range_t, R&&)): Use _M_range_initialize_n for sized
ranges and forward ranges.
(vector::_M_range_initialize(FwIt, FwIt, forward_iterator_tag)):
Likewise.
(vector::_M_range_initialize_n): New function.
* testsuite/23_containers/vector/cons/108487.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
The new C++23 member functions assign_range, insert_range and
append_range were checking whether the begin() iterator changed after
calling the base class member. That works, but is technically undefined
when the original iterator has been invalidated by a change in capacity.
We can just check the capacity directly, because reallocation only
occurs if a change in capacity is required.
N.B. we can't use data() either because std::vector<bool> doesn't have
it.
libstdc++-v3/ChangeLog:
* include/debug/vector (vector::assign_range): Use change in
capacity to detect reallocation.
(vector::insert_range, vector::append_range): Likewise. Remove
unused variables.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
Unlike insert_range and assign_range, the append_range function does not
have a precondition that the range doesn't overlap *this. That means we
need to avoid relocating the existing elements until after copying from
the range. This means I need to revert r15-8488-g3e1d760bf49d0e which
made the from_range_t constructor use append_range, because the
constructor can avoid the additional complexity needed by append_range.
When relocating the existing elements in append_range we can use
std::__relocate_a to do it more efficiently, if that's valid.
std::vector<bool>::append_range needs similar treatment, although it's a
bit simpler as we know that the elements are trivially copyable and so
we don't need to worry about them throwing. assign_range doesn't allow
overlapping ranges, so can be rewritten to be more efficient than
calling append_range for the forward or sized range case.
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h (vector::assign_range): More
efficient implementation for forward/sized ranges.
(vector::append_range): Handle potentially overlapping range.
* include/bits/stl_vector.h (vector(from_range_t, R&&, Alloc)):
Do not use append_range for non-sized input range case.
(vector::append_range): Handle potentially overlapping range.
* include/bits/vector.tcc (vector::insert_range): Forward range
instead of moving it.
* testsuite/23_containers/vector/bool/modifiers/insert/append_range.cc:
Test overlapping ranges.
* testsuite/23_containers/vector/modifiers/append_range.cc:
Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
This avoids a runtime error from Clang's annoying -fsanitize=integer
(even though it's not undefined and behaves correctly).
libstdc++-v3/ChangeLog:
PR libstdc++/119429
* include/std/format (__format::_Scanner::_Scanner): Cast
default argument to size_t.
|
|
These patch add check to verify if common range iterators satisfies
Cpp17LegacyIterator requirements (__detail::__cpp17_input_iterator),
before invoking overloads of insert that accepts two iterators.
As such overloads existed before c++20 iterators were introduced,
they commonly assume existence of iterator_traits<..>::iterator_category,
and passing a cpp20-only iterators, leads to hard errors.
In case if user-defined container wants to support more efficient
insertion in such cases, it should provided insert_range method,
as in the case of standard containers.
PR libstdc++/119415
libstdc++-v3/ChangeLog:
* include/std/flat_set (_Flat_set_impl:insert_range):
Add __detail::__cpp17_input_iterator check.
* testsuite/23_containers/flat_multiset/1.cc: New tests
* testsuite/23_containers/flat_set/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>
|
|
This is the subject of LWG 4228 which notes that libstdc++ doesn't
enforce this requirement. That's just a bug because I forgot to add it
to vector<bool> when adding it elsewhere.
For consistency with the other containers we should not allow incorrect
allocator types for strict -std=c++NN modes, but it is very late to make
that change for GCC 15 so this only enables the assertion for C++20
(where it's required). For GCC 16 we can enable it for strict modes too.
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h (vector<bool, A>): Enforce the
C++20 requirement that the allocator's value_type matches the
container.
* testsuite/23_containers/vector/bool/cons/from_range.cc: Fix
incorrect allocator type.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
|
|
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:
* 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>
|
|
libstdc++-v3/ChangeLog:
* include/bits/locale_facets_nonio.tcc (time_put::do_put): Fix
typo in comment.
|
|
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>
|
|
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>
|
