Tested on x86_64-pc-linux-gnu, does this look OK for trunk/branches?
PR libstdc++/101483
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Iterator::_Iterator): Add
missing std::move.
---
libstdc++-v3/include/std/ranges | 2 +-
1 file changed, 1 insertion(+), 1
In r12-569 I accidentally applied the LWG 3533 change that
was intended for elements_view::iterator::base to
elements_view::base instead.
This patch corrects this, and also applies the corresponding LWG 3533
change to lazy_split_view::inner-iter::base now that we implement P2210.
Tested on
On Mon, 19 Jul 2021, Patrick Palka wrote:
> Constraint subsumption is implemented in two steps. The first step
> computes the disjunctive (or conjunctive) normal form of one of the
> constraints, and the second step verifies that each clause in the
> decomposed form implies the other constraint.
Constraint subsumption is implemented in two steps. The first step
computes the disjunctive (or conjunctive) normal form of one of the
constraints, and the second step verifies that each clause in the
decomposed form implies the other constraint. Performing these two
steps separately is
On Sat, May 8, 2021 at 8:42 AM Jason Merrill wrote:
>
> On 5/7/21 12:33 PM, Patrick Palka wrote:
> > This PR is about CTAD but the underlying problems are more general;
> > CTAD is a good trigger for them because of the necessary substitution
> > into constraints that deduction guide generation
This implements the wording changes of DR 960 which clarifies that two
reference types are covariant only if they're both lvalue references
or both rvalue references.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
DR 960
PR c++/99664
This is the alias CTAD version of the CTAD bug PR93248, and the fix is
the same: clear cp_unevaluated_operand so that the entire chain of
DECL_ARGUMENTS gets substituted.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11?
PR c++/101233
gcc/cp/ChangeLog:
On Wed, 14 Jul 2021, Jason Merrill wrote:
> On 7/14/21 11:26 AM, Patrick Palka wrote:
> > Here we're incorrectly treating T&& as a forwarding reference during
> > CTAD even though T is a template parameter of the class template.
> >
> > This happens because the template parameter T in the
Here we're incorrectly treating T&& as a forwarding reference during
CTAD even though T is a template parameter of the class template.
This happens because the template parameter T in the out-of-line
definition of the constructor doesn't have the flag
TEMPLATE_TYPE_PARM_FOR_CLASS set, and during
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by
This gives the new split_view's sentinel type a defaulted default
constructor, something which was overlooked in r12-1665. This patch
also fixes a couple of other issues with the new split_view as reported
in the PR.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR
This gives the new split_view's sentinel type a defaulted default
constructor, something which was overlooked in r12-1665. This patch
also fixes a couple of other issues with the new split_view as reported
in the PR.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR
On Fri, 9 Jul 2021, Jason Merrill wrote:
> On 7/9/21 4:18 PM, Patrick Palka wrote:
> > On Fri, 9 Jul 2021, Patrick Palka wrote:
> >
> > > On Fri, 9 Jul 2021, Jason Merrill wrote:
> > >
> > > > On 7/9/21 3:18 PM, Patrick Palka wrote:
> > > > > This adds support for declaring (class-scope)
On Fri, 9 Jul 2021, Patrick Palka wrote:
> On Fri, 9 Jul 2021, Jason Merrill wrote:
>
> > On 7/9/21 3:18 PM, Patrick Palka wrote:
> > > This adds support for declaring (class-scope) deduction guides for a
> > > member class template. Fortunately it seems only a couple of changes
> > > are
On Fri, 9 Jul 2021, Jason Merrill wrote:
> On 7/9/21 3:18 PM, Patrick Palka wrote:
> > This adds support for declaring (class-scope) deduction guides for a
> > member class template. Fortunately it seems only a couple of changes
> > are needed in order for the existing CTAD machinery to handle
This adds support for declaring (class-scope) deduction guides for a
member class template. Fortunately it seems only a couple of changes
are needed in order for the existing CTAD machinery to handle them like
any other deduction guide: we need to make sure to give them a
FUNCTION_TYPE instead of
Here we're failing to treat 'new T[N]' as erroneous in a SFINAE context
when T isn't default constructible because expand_aggr_init_1 doesn't
communicate to build_aggr_init (its only SFINAE caller) whether the
initialization was actually successful. To fix this, this patch makes
On Thu, 8 Jul 2021, Jason Merrill wrote:
> On 7/8/21 11:28 AM, Patrick Palka wrote:
> > Here we're crashing ultimately because the mechanism for delaying
> > substitution into a requires-expression (or constexpr if) doesn't
> > expect to see dependent args. But we end up capturing dependent
> >
Here we're crashing ultimately because the mechanism for delaying
substitution into a requires-expression (or constexpr if) doesn't
expect to see dependent args. But we end up capturing dependent
args here when substituting into the default template argument during
coerce_template_parms for the
r12-1989 fixed the testcase in the PR, but unfortunately the fix is
buggy:
1. It breaks the case where the common template between the
TEMPLATE_DECL t and ctx_parms is the innermost template (as in
concepts-memtmpl5.C below). This can be fixed by instead
passing the TREE_TYPE of
On Thu, 1 Jul 2021, Jason Merrill wrote:
> On 6/30/21 5:27 PM, Patrick Palka wrote:
> > Here any_template_parm_r is failing to mark the template parameters
> > that're implicitly used by the unqualified use of 'd' inside the constraint,
> > because the code to do so assumes each level of a
Here any_template_parm_r is failing to mark the template parameters
that're implicitly used by the unqualified use of 'd' inside the constraint,
because the code to do so assumes each level of a template parameter
list points to the corresponding primary template, but here the
parameter level for
On Wed, 30 Jun 2021, Jason Merrill wrote:
> On 6/30/21 10:48 AM, Patrick Palka wrote:
> > On Tue, 29 Jun 2021, Jason Merrill wrote:
> >
> > > On 6/29/21 1:57 PM, Patrick Palka wrote:
> > > > r12-1829 corrected the access scope during partial specialization
> > > > matching of class templates,
On Wed, Jun 30, 2021 at 3:51 PM Jason Merrill wrote:
>
> On 6/30/21 11:58 AM, Patrick Palka wrote:
> > On Wed, 30 Jun 2021, Patrick Palka wrote:
> >
> >> On Fri, 25 Jun 2021, Jason Merrill wrote:
> >>
> >>> On 6/25/21 1:11 PM, Patrick Palka wrote:
> On Fri, 25 Jun 2021, Jason Merrill wrote:
On Wed, 30 Jun 2021, Patrick Palka wrote:
> On Fri, 25 Jun 2021, Jason Merrill wrote:
>
> > On 6/25/21 1:11 PM, Patrick Palka wrote:
> > > On Fri, 25 Jun 2021, Jason Merrill wrote:
> > >
> > > > On 6/24/21 4:45 PM, Patrick Palka wrote:
> > > > > In the first testcase below, during parsing of
On Fri, 25 Jun 2021, Jason Merrill wrote:
> On 6/25/21 1:11 PM, Patrick Palka wrote:
> > On Fri, 25 Jun 2021, Jason Merrill wrote:
> >
> > > On 6/24/21 4:45 PM, Patrick Palka wrote:
> > > > In the first testcase below, during parsing of the alias template
> > > > ConstSpanType, transparency of
On Tue, 29 Jun 2021, Jason Merrill wrote:
> On 6/29/21 1:57 PM, Patrick Palka wrote:
> > When push_access_scope is passed a TYPE_DECL for a class type (which
> > can happen during e.g. satisfaction), we undesirably push only the
> > enclosing context of the class instead of the class itself.
On Tue, 29 Jun 2021, Jason Merrill wrote:
> On 6/29/21 1:57 PM, Patrick Palka wrote:
> > r12-1829 corrected the access scope during partial specialization
> > matching of class templates, but neglected the variable template case.
> > This patch moves the access scope adjustment to inside
> >
Here the initializer for 'x' is represented as an empty CONSTRUCTOR
due to its empty element type. So during constexpr evaluation of the
ARRAY_REF 'x[0]', we end up trying to lazily value initialize the
omitted element at index 0, which fails because the element type is not
default initializable.
When push_access_scope is passed a TYPE_DECL for a class type (which
can happen during e.g. satisfaction), we undesirably push only the
enclosing context of the class instead of the class itself. This causes
us to mishandle e.g. testcase below due to us not entering the scope of
A before checking
r12-1829 corrected the access scope during partial specialization
matching of class templates, but neglected the variable template case.
This patch moves the access scope adjustment to inside
most_specialized_partial_spec, so that all callers can benefit.
Bootstrapped and regtested on
On Fri, 25 Jun 2021, Jason Merrill wrote:
> On 6/25/21 11:03 AM, Patrick Palka wrote:
> > Here, when determining whether the partial specialization matches the
> > specialization has_set_attr_method, we do so from the scope of
> > where the template-id appears rather than from the scope of the
>
On Fri, 25 Jun 2021, Jason Merrill wrote:
> On 6/24/21 4:45 PM, Patrick Palka wrote:
> > In the first testcase below, during parsing of the alias template
> > ConstSpanType, transparency of alias template specializations means we
> > replace SpanType with SpanType's substituted definition. But
On Fri, 25 Jun 2021, Patrick Palka wrote:
> Here, when determining whether the partial specialization matches the
> specialization has_set_attr_method, we do so from the scope of
Er, this should say has_type_method.
> where the template-id appears rather than from the scope of the
>
Here, when determining whether the partial specialization matches the
specialization has_set_attr_method, we do so from the scope of
where the template-id appears rather than from the scope of the
specialization, and this causes us to select the partial specialization
(since Child::type is
In the first testcase below, during parsing of the alias template
ConstSpanType, transparency of alias template specializations means we
replace SpanType with SpanType's substituted definition. But this
substitution lowers the level of the CTAD placeholder for span(T()) from
2 to 1, and so the
On Thu, 24 Jun 2021, Jonathan Wakely via Libstdc++ wrote:
> The LWG issue proposes to add a conditional noexcept-specifier to
> std::unique_ptr's dereference operator. The issue is currently in
> Tentatively Ready status, but even if it isn't voted into the draft, we
> can do it as a conforming
During alias CTAD, we're accidentally ignoring the aggregate deduction
candidate of the underlying template because it's added to the candidate
set separately via maybe_aggr_guide (which doesn't yet handle alias
templates) rather than via deduction_guides_for (which does). This
patch makes
Here we're crashing because cp_fold_function walks into the (templated)
requirements of a requires-expression outside a template, but the
folding routines aren't prepared to handle templated trees. This patch
fixes this by making cp_fold use evaluate_requires_expr to fold a
requires-expression as
On Wed, 23 Jun 2021, Jason Merrill wrote:
> On 6/23/21 2:18 PM, Patrick Palka wrote:
> > We set DECL_CONTEXT on implicitly generated deduction guides so that
> > their access is consistent with that of the constructor. But this
> > apparently leads to excessive instantiation in some cases,
We set DECL_CONTEXT on implicitly generated deduction guides so that
their access is consistent with that of the constructor. But this
apparently leads to excessive instantiation in some cases, ultimately
because instantiation of a deduction guide should be independent of
instantiation of the
On Tue, 22 Jun 2021, Jonathan Wakely wrote:
> On Tue, 22 Jun 2021 at 19:45, Patrick Palka wrote:
> > This change causes us to reject some container CTAD examples in the
> > libstdc++ testsuite due to deduction failure for {}, which AFAICT is the
> > correct behavior. Previously, in the case of
During CTAD, we select the best viable deduction guide via
build_new_function_call, which performs overload resolution on the set
of candidate guides and then forms a call to the guide. As the PR
points out, this latter step is unnecessary and occasionally gives us
the wrong answer since a call
r12-1606 bumped the value of __cpp_lib_ranges defined in ,
but this macro is also defined in , so it needs to
be updated there too.
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value.
---
libstdc++-v3/include/bits/ranges_cmp.h | 2 +-
1 file changed, 1
Here, in C++14 or later, we remember the parentheses around 'a' in the
return statement by using a REF_PARENTHESIZED_P wrapper, which ends up
inhibiting NRVO because we don't look through this wrapper before
checking the conditions for NRVO. This patch fixes this by calling
The delayed processing of conversions to a virtual base inside an NSDMI
assumes the target base type is a (possibly indirect) virtual base of
the current class, but the target base type could also be an indirect
non-virtual base inherited from a virtual base, as in the testcase below.
Since such a
On Wed, 5 May 2021, Patrick Palka wrote:
> On Wed, 5 May 2021, Patrick Palka wrote:
>
> > On Wed, 5 May 2021, Jonathan Wakely wrote:
> >
> > > On 04/05/21 21:42 -0400, Patrick Palka via Libstdc++ wrote:
> > > > This rewrites ranges::minmax and ranges::minmax_element so that it
> > > > performs
libstdc++-v3/ChangeLog:
* include/std/concepts (convertible_to): Just use declval as per
LWG 3557.
---
libstdc++-v3/include/std/concepts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libstdc++-v3/include/std/concepts
b/libstdc++-v3/include/std/concepts
libstdc++-v3/ChangeLog:
* include/std/ranges (transform_view::_Iterator::_S_iter_concept):
Consider _Base instead of _Vp as per LWG 3555.
(elements_view::_Iterator::_S_iter_concept): Likewise.
---
libstdc++-v3/include/std/ranges | 12 ++--
1 file changed, 6
libstdc++-v3/ChangeLog:
* include/std/ranges (split_view::_OuterIter::value_type::begin):
Remove the non-const overload, and remove the copyable constraint
on the const overload as per LWG 3553.
---
libstdc++-v3/include/std/ranges | 6 --
1 file changed, 6
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h
(__detail::__common_iter_use_postfix_proxy): Add
move_constructible constraint as LWG 3546.
(common_iterator::__postfix_proxy): Adjust initializer of
_M_keep as per LWG 3546.
---
This mostly mechanical patch performs the renaming part of P2210R3
"Superior string splitting". It also defines _InnerIter::base()
overloads.
libstdc++-v3/ChangeLog:
* include/std/ranges: Rename views::split to views::lazy_split,
split_view to lazy_split_view, etc. throughout.
This implements the new views::split as specified by P2210R2 "Superior
string splitting".
libstdc++-v3/ChangeLog:
* include/std/ranges (__non_propagating_cache::operator bool):
Define.
(split_view): Define as per P2210.
(views::__detail::__can_split_view): Define.
This implements the part of P2210R2 "Superior String Splitting" that
resolves LWG 3478 for split_view (now named lazy_split_view).
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::_OuterIter::__at_end):
Check _M_trailing_empty.
This implements the wording changes of P2325R3 "Views should not be
required to be default constructible". Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.
For __box, this patch
The header defines simplified copies of some ranges algorithms
in order to avoid including the entirety of ranges_algo.h. A subsequent
patch is going to want to use ranges::search in as well, but
that algorithm is more complicated compared to the other copied ones.
So rather than additionally
On Tue, 15 Jun 2021, Patrick Palka wrote:
> This force-enables perfect forwarding call wrapper semantics whenever
> the extra arguments of a partially applied range adaptor aren't all
> trivially copyable, so as to avoid incurring unnecessary copies of
> potentially expensive-to-copy objects
This force-enables perfect forwarding call wrapper semantics whenever
the extra arguments of a partially applied range adaptor aren't all
trivially copyable, so as to avoid incurring unnecessary copies of
potentially expensive-to-copy objects (such as std::function objects)
when invoking the
The _S_has_simple_extra_args mechanism is used to simplify forwarding
of range adaptor's extra arguments when perfect forwarding call wrapper
semantics isn't required for correctness, on a per-adaptor basis.
Both views::take and views::drop are flagged as such, but it turns out
perfect forwarding
On Thu, Apr 29, 2021 at 7:48 AM Patrick Palka wrote:
>
> On Wed, 28 Apr 2021, Jason Merrill wrote:
>
> > On 4/28/21 2:24 PM, Patrick Palka wrote:
> > > This makes tsubst_arg_types substitute into a function's parameter types
> > > in left-to-right order instead of right-to-left order, in
On Thu, 10 Jun 2021, Jason Merrill wrote:
> On 6/9/21 3:34 PM, Patrick Palka wrote:
> > Here the satisfaction cache is conflating the satisfaction value of the
> > two return-type-requirements because the corresponding constrained
> > 'auto's have level 2, but they capture an empty
On Thu, 10 Jun 2021, Jason Merrill wrote:
> On 6/9/21 3:34 PM, Patrick Palka wrote:
> > During deduction, when the template of a BOUND_TEMPLATE_TEMPLATE_PARM is
> > a template template parameter, we need to consider the
> > TEMPLATE_TEMPLATE_PARAMETER rather than the TEMPLATE_DECL thereof,
> >
On Wed, 9 Jun 2021, Patrick Palka wrote:
> During deduction, when the template of a BOUND_TEMPLATE_TEMPLATE_PARM is
Ah sorry, this should instead say "when the template of _the argument for_
a BOUND_TEMPLATE_TEMPLATE_PARM is ..."
> a template template parameter, we need to consider the
>
Here the satisfaction cache is conflating the satisfaction value of the
two return-type-requirements because the corresponding constrained
'auto's have level 2, but they capture an empty current_template_parms.
This ultimately causes the satisfaction cache to think the type
constraint doesn't
During deduction, when the template of a BOUND_TEMPLATE_TEMPLATE_PARM is
a template template parameter, we need to consider the
TEMPLATE_TEMPLATE_PARAMETER rather than the TEMPLATE_DECL thereof,
because the canonical form of a template template parameter in a
template argument list is the
Here, when resolving the destructor named by Inner::~Inner
(which is valid only before C++20) we end up in cp_parser_lookup_name to
look up the name Inner relative to the scope Inner. The lookup
naturally finds the injected-class-name Inner, and because
is_template is true, we adjust this lookup
Here, when instantiating the dependent alias template
duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
substituting the function decl _S_gcd. Since we have more arg levels
than _S_gcd has parm levels, an old special case in tsubst_function_decl
causes us to unwantedly reduce
On Thu, 3 Jun 2021, Patrick Palka wrote:
> Here, we're rejecting the specialization of g with T=A, F= in the
> first testcase due to a spurious constness mismatch between the type of
> the template argument and the substituted type of F (the substituted
> type has a top-level const). Note that
Here, we're rejecting the specialization of g with T=A, F= in the
first testcase due to a spurious constness mismatch between the type of
the template argument and the substituted type of F (the substituted
type has a top-level const). Note that this mismatch doesn't occur with
object pointers
On Wed, 2 Jun 2021, Jason Merrill wrote:
> On 6/2/21 4:56 PM, Patrick Palka wrote:
> > On Wed, 2 Jun 2021, Patrick Palka wrote:
> >
> > > On Wed, 2 Jun 2021, Jason Merrill wrote:
> > >
> > > > On 6/2/21 2:39 PM, Patrick Palka wrote:
> > > > > Here, the dependent template name in the return type
On Wed, 2 Jun 2021, Patrick Palka wrote:
> On Wed, 2 Jun 2021, Jason Merrill wrote:
>
> > On 6/2/21 2:39 PM, Patrick Palka wrote:
> > > Here, the dependent template name in the return type of f() resolves to
> > > an alias of int& after substitution, and we end up complaining about
> > >
On Wed, 2 Jun 2021, Jason Merrill wrote:
> On 6/2/21 2:39 PM, Patrick Palka wrote:
> > Here, the dependent template name in the return type of f() resolves to
> > an alias of int& after substitution, and we end up complaining about
> > qualifying this reference type with 'const' from
Here, the dependent template name in the return type of f() resolves to
an alias of int& after substitution, and we end up complaining about
qualifying this reference type with 'const' from cp_build_qualified_type
rather than just silently dropping the qualification as per [dcl.ref]/1.
We already
When copying the enumerators imported by a class-scope using-enum
declaration, we need to override current_access_specifier so that
finish_member_declaration gives them the same access as the using-enum
decl. The processing of a using-enum is performed after we've seen the
entire definition of
In the case of value-initializing an object of class type T,
[dcl.init.general]/8 says:
- if T has either no default constructor ([class.default.ctor]) or
a default constructor that is user-provided or deleted, then the
object is default-initialized;
- otherwise, the object is
Here, we're not finding the parameter pack inside the static_assert because
STATIC_ASSERT trees are tcc_exceptional, and we weren't explicitly walking
them in cp_walk_subtrees.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/99893
On Wed, 26 May 2021, Tim Song wrote:
> On Wed, May 26, 2021 at 1:43 PM Patrick Palka wrote:
> >
> > On Wed, 26 May 2021, Tim Song wrote:
> > >
> > > On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++
> > > wrote:
> > > >
> > > > - else if constexpr (input_iterator<_Out>
> > > >
This implements the wording changes of CWG 1315, which permits non-type
template arguments in a partial specialization to use template
parameters more freely. Delightfully, it seems the only change needed
is to remove a few checks from process_partial_specialization.
But that change alone
On Fri, 14 May 2021, Patrick Palka wrote:
> r11-8053 rewrote the range adaptor implementation in conformance with
> P2281, making partial application act like a SFINAE-friendly perfect
> forwarding call wrapper. Making SFINAE-friendliness coexist with
> perfect forwarding here requires adding
On Wed, 26 May 2021, Tim Song wrote:
> I noticed that output_iterator_wrapper still has a (non-void)
> value_type. Perhaps we can get better coverage if it doesn't have one?
> The existing tests should have caught this case with that change, at least.
Good point, and I guess it should be fine to
When input_iterator<_Out> isn't satisfied, we need to avoid substituting
into iter_value_t<_Out> because the latter isn't necessarily
well-formed in that case. To that end, this patch rewrites the
problematic condition in ranges::unique_copy into a nested requirement
which has the correct
On Tue, 25 May 2021, Jason Merrill wrote:
> On 5/25/21 10:50 AM, Patrick Palka wrote:
> > On Mon, 24 May 2021, Jason Merrill wrote:
> >
> > > On 5/21/21 4:35 PM, Patrick Palka wrote:
> > > > Here, during ahead of time access checking for the private member
> > > > EnumeratorRange::end_reached_
On Mon, 24 May 2021, Jason Merrill wrote:
> On 5/24/21 1:48 PM, Patrick Palka wrote:
> > In the testcase below, the initializer for C::b inside C's default
> > constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in
> > C++17 mode. During massaging of this constexpr constructor,
>
On Mon, 24 May 2021, Jason Merrill wrote:
> On 5/21/21 4:35 PM, Patrick Palka wrote:
> > Here, during ahead of time access checking for the private member
> > EnumeratorRange::end_reached_ in the hidden friend f, we're triggering
> > the the assert in enforce_access that verifies we're not trying
In the testcase below, the initializer for C::b inside C's default
constructor is encoded as a TARGET_EXPR wrapping the CALL_EXPR f() in
C++17 mode. During massaging of this constexpr constructor,
build_target_expr_with_type called from bot_manip ends up trying to use
B's implicitly deleted copy
Here, during ahead of time access checking for the private member
EnumeratorRange::end_reached_ in the hidden friend f, we're triggering
the the assert in enforce_access that verifies we're not trying to add a
dependent access check to TI_DEFERRED_ACCESS_CHECKS.
The special thing about this class
Here, in C++17 mode, convert_nontype_argument_function is rejecting
binding a non-noexcept function reference template parameter to a
noexcept function (encoded as the template argument '*(int (&) (int)) ').
The first roadblock to making this work is that the argument is wrapped
an an implicit
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
libstdc++-v3/ChangeLog:
PR libstdc++/100606
* include/std/ranges (drop_while_view::begin): Assert the
precondition added by LWG 3490.
---
libstdc++-v3/include/std/ranges | 1 +
1 file changed, 1 insertion(+)
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11/10?
libstdc++-v3/ChangeLog:
PR libstdc++/100690
* include/std/ranges (iota_view::_Sentinel::_M_distance_from):
Split out into this member function from ...
(iota_view::_Sentinel::operator-): ... here,
This adds support for defining range adaptors with defaultable arguments.
No such range adaptors have yet been standardized, but range-v3 has a
couple, e.g. 'unique' and 'sample' (which are approximately implemented
in the added testcase), and it would be good to preemptively support
such
On Tue, 18 May 2021, Patrick Palka wrote:
> This implements the P0896 changes to reverse_view's member types
Whoops, s/reverse_view/reverse_iterator rather... consider this typo
fixed throughout.
> value_type, difference_type and reference in C++20 mode, which fixes
> problems taking the
This implements the P0896 changes to reverse_view's member types
value_type, difference_type and reference in C++20 mode, which fixes
problems taking the reverse_iterator of an iterator with a non-integral
difference_type (such as iota_view).
Tested on x86_64-pc-linux-gnu, does this look OK for
In the earlier commit r12-854 I forgot to also rewrite the other operator-
overload in terms of the split-out member function _M_distance_from.
Tested on x86_64-pc-linux-gnu, committed as obvious.
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges
On Mon, 17 May 2021, Tim Song wrote:
> On Mon, May 17, 2021 at 2:59 PM Patrick Palka wrote:
> >
> > + constexpr _CachedPosition&
> > + operator=(_CachedPosition&& __other) noexcept
> > + {
> > + if (std::__addressof(__other) != this)
>
> I don't think we need this
On Mon, 17 May 2021, Tim Song wrote:
> On Mon, May 17, 2021 at 12:21 PM Patrick Palka via Gcc-patches
> wrote:
> >
> > using _Base = elements_view::_Base<_Const>;
> > sentinel_t<_Base> _M_end = sentinel_t<_Base>();
> >
On Mon, 17 May 2021, Tim Song wrote:
> On Mon, May 17, 2021 at 11:46 AM Patrick Palka via Libstdc++
> wrote:
> > constexpr void
> > _M_set(const _Range&, const iterator_t<_Range>& __it)
> > {
> > __glibcxx_assert(!_M_has_value());
> > - _M_iter = __it;
>
A range being a random access range is not a sufficient condition for
ranges::next(iter, sent) to have constant time complexity; the range
must also have a sized sentinel. This adjusts the memoization condition
for reverse_view accordingly.
Tested on x86_64-pc-linxu-gnu, does this look OK for
Tested on x86_64-pc-linux-gnu, does this look OK for 10/11/trunk?
libstdc++-v3/ChangeLog:
PR libstdc++/100631
* include/std/ranges (elements_view::_Iterator): Befriend
_Sentinel.
(elements_view::_Sentinel::_M_equal): Templatize.
This makes the in-place constructor of our partial specialization of
__box for already-semiregular types to use direct-non-list-initialization
(in accordance with the specification of the primary template), and
additionally makes its data() member function use std::__addressof.
Tested on
This fixes two issues with our iterator caching as described in detail
in the PR. Since r12-336 added the __non_propagating_cache class
template as part of P2328, this patch just rewrites the _CachedPosition
partial specialization in terms of this class template.
Tested on x86_64-pc-linux-gnu,
801 - 900 of 1377 matches
Mail list logo
