| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
libstdc++-v3/ChangeLog:
* include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
Add parentheses to avoid -Wparentheses warning.
|
|
[PR118035]
Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g. std::copy(first, last, first) which
violates the preconditions for the algorithms.
This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.
libstdc++-v3/ChangeLog:
PR libstdc++/118035
* include/bits/deque.tcc (_M_range_insert_aux): Return
immediately if inserting an empty range.
* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
test.
|
|
|
|
Currently the _M_bucket members are left uninitialized for
default-initialized local iterators, and then copy construction copies
indeterminate values. We should just ensure they're initialized on
construction.
Setting them to zero makes default-initialization consistent with
value-initialization and avoids indeterminate values.
For the _Local_iterator_base<..., false> specialization we preserve the
existing behaviour of setting _M_bucket_count to -1 in the default
constructor, as a sentinel value to indicate there's no hash object
present.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_Local_iterator_base): Use
default member-initializers.
|
|
This file is only for C++11 and later, so replace typedefs with
alias-declarations for clarity. Also remove redundant std::
qualification on size_t, ptrdiff_t etc.
We can also remove the result_type, first_argument_type and
second_argument_type typedefs from the range hashers. We don't need
those types to follow the C++98 adaptable function object protocol.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h: Replace typedefs with
alias-declarations. Remove redundant std:: qualification.
(_Mod_range_hashing, _Mask_range_hashing): Remove adaptable
function object typedefs.
|
|
The fix for PR libstdc++/56267 (relating to the lifetime of the hash
object stored in a local iterator) has undefined behaviour, as it relies
on being able to call a member function on an empty object that never
started its lifetime. Although the member function probably doesn't care
about the empty object's state, this is still technically undefined
because there is no object of that type at that address. It's also
possible that the hash object would have a stricter alignment than the
_Hash_code_storage object, so that the reinterpret_cast would produce a
misaligned pointer.
This fix replaces _Local_iterator_base's _Hash_code_storage base-class
with a new class template containing a potentially-overlapping (i.e.
[[no_unique_address]]) union member. This means that we always have
storage of the correct type, and it can be initialized/destroyed when
required. We no longer need a reinterpret_cast that gives us a pointer
that we should not dereference.
It would be nice if we could just use a union containing the _Hash
object as a data member of _Local_iterator_base, but that would be an
ABI change. The _Hash_code_storage that contains the _Hash object is the
first base-class, before the _Node_iterator_base base-class. Making the
union a data member of _Local_iterator_base would make it come after the
_Node_iterator_base base instead of before it, altering the layout.
Since we're changing _Hash_code_storage anyway, we can replace it with a
new class template that stores the _Hash object itself in the union,
rather than a _Hash_code_base that holds the _Hash. This removes an
unnecessary level of indirection in the class hierarchy. This change
requires the effects of _Hash_code_base::_M_bucket_index to be inlined
into the _Local_iterator_base::_M_incr function, but that's easy.
We don't need separate specializations of _Hash_obj_storage for an empty
hash function and a non-empty one. Using [[no_unique_address]] gives us
an empty base-class when possible.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_Hash_code_storage): Remove.
(_Hash_obj_storage): New class template. Store the hash
function as a union member instead of using a byte buffer.
(_Local_iterator_base): Use _Hash_obj_storage instead of
_Hash_code_storage, adjust members that construct and destroy
the hash object.
(_Local_iterator_base::_M_incr): Calculate bucket index.
|
|
The main change here is using [[no_unique_address]] instead of the Empty
Base-class Optimization. Using the attribute allows us to use data
members instead of base-classes. That simplifies the inheritance
hierarchy, which means less work for the compiler. It also means that
ADL has fewer associated classes and associated namespaces to consider,
further reducing the work the compiler has to do.
Reducing the differences between the _Hashtable_ebo_helper primary
template and the partial specialization means we no longer need to use
member functions to access the stored object, because it's now always a
data member called _M_obj. This means we can also remove a number of
other helper functions that were using those member functions to access
the object, for example we can swap the _Hash and _Equal objects
directly in _Hashtable::swap instead of calling _Hashtable_base::_M_swap
which then calls _Hash_code_base::_M_swap.
Although [[no_unique_address]] would allow us to reduce the size for
empty types that are also 'final', doing so would be an ABI break
because those types were previously excluded from using the EBO. So we
still need the _Hashtable_ebo_helper class template and a partial
specialization, so that we only use the attribute under exactly the same
conditions as we previously used the EBO. This could be avoided with a
non-standard [[no_unique_address(expr)]] attribute that took a boolean
condition, or with reflection and token sequence injection, but we don't
have either of those things.
Because _Hashtable_ebo_helper is no longer used as a base-class we don't
need to disambiguate possible identical bases, so it doesn't need an
integral non-type template parameter.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_Hashtable::swap): Swap hash
function and equality predicate here. Inline allocator swap
instead of using __alloc_on_swap.
* include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
Replace EBO with no_unique_address attribute. Remove NTTP.
(_Hash_code_base): Replace base class with data member using
no_unique_address attribute.
(_Hash_code_base::_M_swap): Remove.
(_Hash_code_base::_M_hash): Remove.
(_Hashtable_base): Replace base class with data member using
no_unique_address attribute.
(_Hashtable_base::_M_swap): Remove.
(_Hashtable_alloc): Replace base class with data member using
no_unique_address attribute.
|
|
The union members I used in the new _Node types for fancy pointers only
work for value types that are trivially default constructible. This
change replaces the anonymous union with a named union so it can be
given a default constructor and destructor, to leave the variant member
uninitialized.
This also fixes the incorrect macro names in the alloc_ptr_ignored.cc
tests as pointed out by François, and fixes some std::list pointer
confusions that the fixed alloc_ptr_ignored.cc test revealed.
libstdc++-v3/ChangeLog:
PR libstdc++/57272
* include/bits/forward_list.h (__fwd_list::_Node): Add
user-provided special member functions to union.
* include/bits/stl_list.h (__list::_Node): Likewise.
(_Node_base::_M_hook, _Node_base::swap): Use _M_base() instead
of std::pointer_traits::pointer_to.
(_Node_base::_M_transfer): Likewise. Add noexcept.
(_List_base::_M_put_node): Use 'if constexpr' to avoid using
pointer_traits::pointer_to when not necessary.
(_List_base::_M_destroy_node): Fix parameter to be the pointer
type used internally, not the allocator's pointer.
(list::_M_create_node): Likewise.
* testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr.cc:
Check explicit instantiation of non-trivial value type.
* testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr.cc:
Likewise.
* testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr_ignored.cc:
Fix macro name.
* testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr_ignored.cc:
Likewise.
|
|
|
|
libstdc++-v3/ChangeLog:
* include/c_compatibility/wchar.h (fgetwc): Remove duplicate
using-declaration.
|
|
|
|
Use a local reference for the (now possibly lifetime extended) result of
*__first so that we copy it only when necessary.
PR libstdc++/112349
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__min_fn::operator()): Turn local
object __tmp into a reference.
* include/bits/ranges_util.h (__max_fn::operator()): Likewise.
* testsuite/25_algorithms/max/constrained.cc (test04): New test.
* testsuite/25_algorithms/min/constrained.cc (test04): New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
|
|
I noticed a -Wmaybe-uninitialized warning for this function, which turns
out to be correct. If the caller passes a valid std::ios_base::seekdir
value then there's no problem, but if they pass std::seekdir(999) then
we don't initialize the __base variable before adding it to __off.
Rather than initialize it to an arbitrary value, we should return an
error.
Also add [[unlikely]] attributes to the paths that return an error.
libstdc++-v3/ChangeLog:
* include/std/spanstream (basic_spanbuf::seekoff): Return an
error for invalid seekdir values.
|
|
Although this should never make a difference for sensible code, we
should really make the expression in the noexcept-specifier match the
expression in the function body.
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (not_equal_to): Make order of
expressions in noexcept-specifier match the body.
* testsuite/20_util/function_objects/range.cmp/not_equal_to.cc:
Check noexcept.
|
|
libstdc++-v3/ChangeLog:
* include/bits/regex.tcc: Fix -Wsign-compare warning.
|
|
libstdc++-v3/ChangeLog:
* include/pstl/parallel_backend_tbb.h (__merge_func): Fix order
of mem-initializers.
|
|
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/random_device/entropy.cc: Fix
indentation to avoid -Wmisleading-indentation warning.
|
|
|
|
libstdc++-v3/ChangeLog:
* testsuite/23_containers/unordered_map/modifiers/reserve.cc:
Cast to size_t to fix -Wsign-compare warning.
* testsuite/23_containers/unordered_set/hash_policy/71181.cc:
Likewise.
* testsuite/23_containers/unordered_set/insert/move_range.cc:
Likewise.
|
|
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_Local_iterator_base): Fix
-Wsign-compare warnings.
|
|
libstdc++-v3/ChangeLog:
* src/c++17/fs_dir.cc: Fix typo in comment.
|
|
|
|
Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.
This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.
libstdc++-v3/ChangeLog:
PR libstdc++/109517
PR libstdc++/109976
* include/debug/helper_functions.h (__valid_range_aux): Treat
all input iterator ranges as valid during constant evaluation.
|
|
As PR c++/106212 shows, the Debug Mode checks cause a compilation error
for equality comparisons involving std::array prvalues in constant
expressions. Those Debug Mode checks are redundant when
comparing two std::array objects, because we already know we have a
valid range. We can also avoid the unnecessary step of using
std::__niter_base to do __normal_iterator unwrapping, which isn't needed
because our std::array iterators are just pointers. Using
std::__equal_aux1 instead of std::equal avoids the redundant checks in
std::equal and std::__equal_aux.
libstdc++-v3/ChangeLog:
PR libstdc++/106212
* include/std/array (operator==): Use std::__equal_aux1 instead
of std::equal.
* testsuite/23_containers/array/comparison_operators/106212.cc:
New test.
|
|
As PR c++/117966 shows, the Debug Mode checks cause a compilation error
for a global constexpr std::span. Those debug checks are redundant when
constructing from an array or a range, because we already know we have a
valid range and we know its size. Instead of delegating to the
std::span(contiguous_iterator, contiguous_iterator) constructor, just
initialize the data members directly.
libstdc++-v3/ChangeLog:
PR libstdc++/117966
* include/std/span (span(T (&)[N])): Do not delegate to
constructor that performs redundant checks.
(span(array<T, N>&), span(const array<T, N>&)): Likewise.
(span(Range&&), span(const span<T, N>&)): Likewise.
* testsuite/23_containers/span/117966.cc: New test.
|
|
This was approved in Wrocław as LWG 3900, so that passing an incorrect
argument intended as an allocator will be ill-formed, instead of
silently ignored.
This also renames the template parameters and function parameters for
the allocators, to align with the names in the standard. I found it too
confusing to have a parameter _Alloc which doesn't correspond to Alloc
in the standard. Rename _Alloc to _Allocator (which the standard calls
Allocator) and rename _Na to _Alloc (which the standard calls Alloc).
libstdc++-v3/ChangeLog:
* include/std/generator (_Promise_alloc): Rename template
parameter. Use __alloc_rebind to rebind allocator.
(_Promise_alloc::operator new): Replace constraints with a
static_assert in the body. Rename allocator parameter.
(_Promise_alloc<void>::_M_allocate): Rename allocator parameter.
Use __alloc_rebind to rebind allocator.
(_Promise_alloc<void>::operator new): Rename allocator
parameter.
* testsuite/24_iterators/range_generators/alloc.cc: New test.
* testsuite/24_iterators/range_generators/lwg3900.cc: New test.
Reviewed-by: Arsen Arsenović <arsen@aarsen.me>
|
|
This was just approved in Wrocław.
libstdc++-v3/ChangeLog:
* include/std/ostream (println): Pass stream's locale to
std::format, as per LWG 4088.
* testsuite/27_io/basic_ostream/print/1.cc: Check std::println
with custom locale. Remove unused brit_punc class.
|
|
|
|
Check the __glibcxx_polymorphic_allocator macro instead of just checking
whether __cplusplus > 201703L.
libstdc++-v3/ChangeLog:
* include/bits/memory_resource.h (polymoprhic_allocator): Use
feature test macro for P0339R6 features.
|
|
This patch implements P2865R5 by promoting the warning to permerror in
C++26 only.
In C++20 we should warn even without -Wall. Jason fixed this in r15-5713
but let's add a test that doesn't use -Wall.
This caused a FAIL in conditionally_borrowed.cc because we end up
comparing two array types in equality_comparable_with ->
__weakly_eq_cmp_with. That could be fixed in libstc++, perhaps by
adding std::decay in the appropriate place.
PR c++/117788
gcc/c-family/ChangeLog:
* c-warn.cc (do_warn_array_compare): Emit a permerror in C++26.
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op) <case EQ_EXPR>: Don't check
warn_array_compare. Check tf_warning_or_error instead of just
tf_warning. Maybe return an error_mark_node in C++26.
<case LE_EXPR>: Likewise.
gcc/testsuite/ChangeLog:
* c-c++-common/Warray-compare-1.c: Expect an error in C++26.
* c-c++-common/Warray-compare-3.c: Likewise.
* c-c++-common/Warray-compare-4.c: New test.
* c-c++-common/Warray-compare-5.c: New test.
* g++.dg/warn/Warray-compare-1.C: New test.
libstdc++-v3/ChangeLog:
* testsuite/std/ranges/adaptors/conditionally_borrowed.cc: Add a
FIXME, adjust.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
This reverts r15-6060-ge4a0157c2397c9 so that __is_bitwise_relocatable
depends only on is_trivial. To avoid the deprecation warnings for C++26,
use the __is_trivial built-in directly instead of std::is_trivial.
We need to be sure that the type is trivially copyable, not just
trivially constructible and trivially assignable. Otherwise we get
-Wclass-memaccess diagnostics for e.g. std::vector<std::pair<A*, B*>>.
We could add is_trivially_copyable to the conditions, but this isn't
really an appropriate change for stage 3 anyway (it affects all modes
from C++11 upwards). Just revert to using is_trivial, and we can revisit
the condition for GCC 16.
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (__is_bitwise_relocatable):
Revert to depending on is_trivial.
|
|
This actually implements P3247R2 by deprecating the is_trivial type
trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits: Deprecate is_trivial and
is_trivial_v.
* include/experimental/type_traits: Suppress the deprecation
warning.
* testsuite/20_util/is_trivial/requirements/explicit_instantiation.cc:
Amend the test to suppress the deprecation warning.
* testsuite/20_util/is_trivial/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/is_trivial/value.cc: Likewise.
* testsuite/20_util/variable_templates_for_traits.cc: Likewise.
* testsuite/experimental/type_traits/value.cc: Likewise.
* testsuite/18_support/max_align_t/requirements/2.cc: Update the
test with P3247R2's new wording.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
In preparation for the deprecation of is_trivial (P3247R2).
Mostly a mechanical exercise, replacing is_trivial with
is_trivially_copyable and/or is_trivially_default_constructible
depending on the cases.
libstdc++-v3/ChangeLog:
* testsuite/20_util/specialized_algorithms/uninitialized_copy/102064.cc:
Port away from is_trivial.
* testsuite/20_util/specialized_algorithms/uninitialized_copy_n/102064.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_default/94540.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_default_n/94540.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/102064.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/102064.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct/94540.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/94540.cc:
Likewise.
* testsuite/23_containers/vector/cons/94540.cc: Likewise.
* testsuite/25_algorithms/copy/move_iterators/69478.cc:
Likewise.
* testsuite/25_algorithms/copy_backward/move_iterators/69478.cc:
Likewise.
* testsuite/25_algorithms/move/69478.cc: Likewise.
* testsuite/25_algorithms/move_backward/69478.cc: Likewise.
* testsuite/25_algorithms/rotate/constrained.cc: Likewise.
* testsuite/25_algorithms/rotate_copy/constrained.cc: Likewise.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
In preparation for the deprecation of is_trivial (P3247R2).
The rangified uninitialized_* specialized memory algorithms have code
paths where they call the non-uninitialized versions, because the latter
are usually optimized. The detection in these code paths uses is_trivial;
port it away from it towards more specific checks.
The detection for the copy/move algorithms was suspicious: it checked
that the output type was trivial, and that assignment from the input
range reference type was nothrow. If so, the algorithm would copy/move
assign (by calling the ranges::copy/move algorithms) instead of
constructing elements. I think this is off because:
1) the constructor that would be called by the algorithm (which may be
neither a copy or a move constructor) wasn't checked. If that
constructor isn't trivial the caller might detect that we're not
calling it, and that goes against the algorithms' specifications.
2) a nothrow assignment is necessary but not sufficient, as again we
need to check for triviality, or the caller can detect we're calling
an assignment operator we were never meant to be calling from these
algorithms.
Therefore I've amended the respective detections.
libstdc++-v3/ChangeLog:
* include/bits/ranges_uninitialized.h: port some if
constexpr away from is_trivial, and towards more specific
detections instead.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
In preparation for the deprecation of is_trivial (P3247R2).
"bitwise relocation" (or "trivial relocation" à la P1144/P2786)
doesn't need the full-fledged notion of triviality, just checking for a
trivial move constructor and a trivial destructor is sufficient.
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h: Amended the
__is_bitwise_relocatable type trait.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
In preparation for the deprecation of is_trivial (P3247R2).
Unfortunately I am unable to fully understand what aspect of triviality
seems to matter for these algorithms, so I just ported is_trivial to its
direct equivalent (trivially copyable + trivially default
constructible.)
libstdc++-v3/ChangeLog:
* include/pstl/algorithm_impl.h (__remove_elements): Port away
from is_trivial.
(__pattern_inplace_merge): Likewise.
* include/pstl/glue_memory_impl.h (uninitialized_copy): Likewise.
(uninitialized_copy_n): Likewise.
(uninitialized_move): Likewise.
(uninitialized_move_n): Likewise.
(uninitialized_default_construct): Likewise.
(uninitialized_default_construct_n): Likewise.
(uninitialized_value_construct): Likewise.
(uninitialized_value_construct_n): Likewise.
* testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/pstl/uninitialized_fill_destroy.cc:
Likewise.
* testsuite/25_algorithms/pstl/alg_modifying_operations/partition.cc:
Likewise.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
In preparation for the deprecation of is_trivial (P3247R2), stop using
it from std::string_view. Also, add the same detection to std::string
(described in [strings.general]/2).
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Add a static_assert on the
char-like type.
* include/std/string_view: Port away from is_trivial.
Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
|
|
On macOS and FreeBSD the read(2) system call can return EINVAL for large
sizes, so limit the maximum that we try to read. The calling code in
basic_filebuf::xsgetn will loop until it gets the size it wants, so we don't
need to loop in basic_file::xsgetn, just limit the maximum size.
libstdc++-v3/ChangeLog:
PR libstdc++/102259
* config/io/basic_file_stdio.cc (basic_file::xsgetn): Limit n to
_GLIBCXX_MAX_READ_SIZE if that macro is defined.
* config/os/bsd/darwin/os_defines.h (_GLIBCXX_MAX_READ_SIZE):
Define to INT_MAX-1.
* config/os/bsd/freebsd/os_defines.h (_GLIBCXX_MAX_READ_SIZE):
Likewise.
|
|
This was removed by P2868R3, voted into the C++26 draft at the November
2023 meeting in Kona. We've had a deprecated warning in place for three
years.
libstdc++-v3/ChangeLog:
* include/bits/allocator.h (allocator::is_always_equal): Do not
define for C++26.
(allocator<void>::is_always_equal): Likewise.
* testsuite/20_util/allocator/requirements/typedefs.cc: Check
that is_always_equal is not present in C++26.
* testsuite/20_util/allocator/void.cc: Do not require
is_always_equal for C++26.
* testsuite/23_containers/vector/bool/cons/constexpr.cc: Add
missing override of base's is_always_equal.
* testsuite/23_containers/vector/cons/constexpr.cc: Likewise.
|
|
Using a stateful allocator with std::vector would fail in Debug Mode,
because the allocator-extended move constructor tries to swap all the
attached safe iterators, but that uses a non-inline function which isn't
constexpr. We don't actually need to swap any iterators in constant
expressions, because we never attach them to the container in the first
place.
This bug went unnoticed because the tests for constexpr std::vector were
using a stateful allocator with a std::allocator base class, but were
failing to override the inherited is_always_equal trait from
std::allocator. That meant that the allocators took the always-equal
code paths, and didn't try to use the buggy constructor. In C++26 the
std::allocator::is_always_equal trait goes away, and so the tests
changed behaviour, revealing the bug.
libstdc++-v3/ChangeLog:
PR libstdc++/117962
* include/debug/safe_container.h: Make allocator-extended move
constructor a no-op during constant evaluation.
|
|
These new tests fail in Debug Mode because the allocator types aren't
equality comparable.
libstdc++-v3/ChangeLog:
PR libstdc++/117921
* testsuite/23_containers/set/modifiers/swap/adl.cc: Add
equality comparison for Allocator.
* testsuite/23_containers/unordered_set/modifiers/swap-2.cc:
Likewise.
|
|
|
|
libstdc++-v3/ChangeLog:
* include/std/format: Fix typo in Doxygen comment.
|
|
According to the editorconfig file format description, a match against
one of multiple different strings is described with those different
strings separated by commas and within curly braces. E.g.
[{x,y}.txt]
https://editorconfig.org/, under "Wildcard Patterns".
The current libstdc++-v3/.editorconfig file has a few places where we
match against similar globs by using strings separated by commas but
without the curly braces. E.g.
[*.h,*.cc]
This doesn't take affect in neovim nor emacs (as far as I can tell), I
haven't looked into other editors.
I would expect that following the standard syntax described in the
documentation would satisfy more editors. Hence this patch suggests
following that standard by using something like:
[*.{h,cc}]
libstdc++-v3/ChangeLog:
* .editorconfig: Adjust globbing style to standard syntax.
Signed-off-by: Matthew Malcomson <mmalcomson@nvidia.com>
|
|
|
|
The standard says that Compare, Pred and Hash objects should be swapped
as described in [swappable.requirements] which means calling swap
unqualified with std::swap visible to name lookup.
libstdc++-v3/ChangeLog:
PR libstdc++/117921
* include/bits/hashtable_policy.h (_Hash_code_base::_M_swap):
Use ADL swap for Hash members.
(_Hashtable_base::_M_swap): Use ADL swap for _Equal members.
* include/bits/stl_tree.h (_Rb_tree::swap): Use ADL swap for
_Compare members.
* testsuite/23_containers/set/modifiers/swap/adl.cc: New test.
* testsuite/23_containers/unordered_set/modifiers/swap-2.cc: New
test.
|
|
|
|
The standard says that std::exclusive_scan can be used to work in
place, i.e. where the output range is the same as the input range. This
means that the first sum cannot be written to the output until after
reading the first input value, otherwise we'll already have overwritten
the first input value.
While writing a new testcase I also realised that the serial version of
std::exclusive_scan uses copy construction for the accumulator variable,
but the standard only requires Cpp17MoveConstructible. We also require
move assignable, which is missing from the standard's requirements, but
we should at least use move construction not copy construction.
A similar problem exists for some other new C++17 numeric algos, but
I'll fix the others in a subsequent commit.
libstdc++-v3/ChangeLog:
PR libstdc++/108236
* include/pstl/glue_numeric_impl.h (exclusive_scan): Pass __init
as rvalue.
* include/pstl/numeric_impl.h (__brick_transform_scan): Do not
write through __result until after reading through __first. Move
__init into return value.
(__pattern_transform_scan): Pass __init as rvalue.
* include/std/numeric (exclusive_scan): Move construct instead
of copy constructing.
* testsuite/26_numerics/exclusive_scan/2.cc: New test.
* testsuite/26_numerics/pstl/numeric_ops/108236.cc: New test.
|
|
Use diagnostic pragmas to allow using `if constexpr` in C++11 mode, so
that we don't need to use tag dispatching.
These helpers could be removed entirely by just using `if constexpr`
directly in the container member functions, but that's a slightly larger
change that can happen later.
It also looks like we could remove the __alloc_on_copy(const Alloc&)
overload, which is unused.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (__do_alloc_on_copy): Remove.
(__do_alloc_on_move __do_alloc_on_swap): Remove.
(__alloc_on_copy, __alloc_on_move, __alloc_on_swap): Use if
constexpr.
|
