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_ in
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 short-ci
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
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 fal
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 reveale
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>
> > > > -
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
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 zero-ini
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 the
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
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 cp_build_qual
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
> > > qualifyi
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
Here, we're rejecting the specialization of g with T=A, F=&f in the
first testcase due to a spurious constness mismatch between the type of
the template argument &f and the substituted type of F (the substituted
type has a top-level const). Note that this mismatch doesn't occur with
object pointer
On Thu, 3 Jun 2021, Patrick Palka wrote:
> Here, we're rejecting the specialization of g with T=A, F=&f in the
> first testcase due to a spurious constness mismatch between the type of
> the template argument &f and the substituted type of F (the substituted
> type has a top-level const). Note th
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 args
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 r
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 TEMPLATE_
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 depen
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
> TEMPLAT
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,
> > bec
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 current_templat
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 accordanc
Here during partial ordering of the two partial specializations we end
up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash shortly
thereafter because uses_template_parms calls potential_constant_expression
which doesn't handle NONTYPE_ARGUMENT_PACK.
This patch fixes this by checking depende
On Fri, 1 Oct 2021, Jason Merrill wrote:
> On 10/1/21 09:46, Patrick Palka wrote:
> > Here during partial ordering of the two partial specializations we end
> > up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash shortly
> > thereafter because uses_template_parms calls potential_constant_ex
On Fri, 1 Oct 2021, Jason Merrill wrote:
> On 10/1/21 10:26, Patrick Palka wrote:
> > On Fri, 1 Oct 2021, Jason Merrill wrote:
> >
> > > On 10/1/21 09:46, Patrick Palka wrote:
> > > > Here during partial ordering of the two partial specializations we end
> > > > up in unify with parm=arg=NONTYPE_
Here we're crashing when level-lowering the variadic constraints on the
template template parameter TT because tsubst_pack_expansion expects
processing_template_decl to be set during a partial substitution.
bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11? Also te
On Fri, Oct 1, 2021 at 1:29 PM Patrick Palka wrote:
>
> On Fri, 1 Oct 2021, Jason Merrill wrote:
>
> > On 10/1/21 10:26, Patrick Palka wrote:
> > > On Fri, 1 Oct 2021, Jason Merrill wrote:
> > >
> > > > On 10/1/21 09:46, Patrick Palka wrote:
> > > > > Here during partial ordering of the two partia
On Fri, 1 Oct 2021, Patrick Palka wrote:
> On Fri, Oct 1, 2021 at 1:29 PM Patrick Palka wrote:
> >
> > On Fri, 1 Oct 2021, Jason Merrill wrote:
> >
> > > On 10/1/21 10:26, Patrick Palka wrote:
> > > > On Fri, 1 Oct 2021, Jason Merrill wrote:
> > > >
> > > > > On 10/1/21 09:46, Patrick Palka wrote
When passing a function template as the argument to a function NTTP
inside a template, we resolve it to the right specialization ahead of
time via resolve_address_of_overloaded_function, though the call to
mark_used within defers odr-using it until instantiation time (as usual).
But at instantiatio
Here uses_template_parms is returning false for the dependent type
A<&impl::i>, which causes tsubst_aggr_type to think it's non-dependent
and not bothering substituting into it, leading to breakage.
This patch fixes this by making has_value_dependent_address also return
true for templated static l
On Mon, 4 Oct 2021, Patrick Palka wrote:
> When passing a function template as the argument to a function NTTP
> inside a template, we resolve it to the right specialization ahead of
> time via resolve_address_of_overloaded_function, though the call to
> mark_used within defers odr-using it until
On Tue, 5 Oct 2021, Jason Merrill wrote:
> On 10/5/21 15:17, Patrick Palka wrote:
> > On Mon, 4 Oct 2021, Patrick Palka wrote:
> >
> > > When passing a function template as the argument to a function NTTP
> > > inside a template, we resolve it to the right specialization ahead of
> > > time via r
On Wed, 6 Oct 2021, Patrick Palka wrote:
> On Tue, 5 Oct 2021, Jason Merrill wrote:
>
> > On 10/5/21 15:17, Patrick Palka wrote:
> > > On Mon, 4 Oct 2021, Patrick Palka wrote:
> > >
> > > > When passing a function template as the argument to a function NTTP
> > > > inside a template, we resolve
We're implementing [temp.param]/10 at parse time but not also at
substitution time.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/61355
gcc/cp/ChangeLog:
* pt.c (convert_template_argument): Perform array/function to
pointer conver
On Wed, 6 Oct 2021, Jason Merrill wrote:
> On 10/6/21 15:52, Patrick Palka wrote:
> > On Wed, 6 Oct 2021, Patrick Palka wrote:
> >
> > > On Tue, 5 Oct 2021, Jason Merrill wrote:
> > >
> > > > On 10/5/21 15:17, Patrick Palka wrote:
> > > > > On Mon, 4 Oct 2021, Patrick Palka wrote:
> > > > >
> >
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::_Iterator): Befriend iota_view.
(iota_view::_Sentinel): Likewise.
(iota_view::iota_view): Add three overloads each taking an
iterator/sentinel pair as per LWG 3523.
* testsuite/std/ranges/iota/iota_vie
This implements P1739R4 along with the resolution for LWG 3407 which
corrects the paper's wording.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (views::_Drop): Forward declare.
(subrange): Befriend views::_Drop.
This patch also reverts the r11-3504 workaround since it's made obsolete
by this resolution.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (view_interface): Forward declare.
(__detail::__is_derived_from_view_
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h
(__detail::__uses_nonqualification_pointer_conversion): Define
and use it ...
(__convertible_to_nonslicing): ... here, as per LWG 3470.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
(The branches don't have P2325R3.)
libstdc++-v3/ChangeLog:
* include/std/ranges (basic_istream_view::_M_object): Value
initialize as per LWG 3568.
---
libstdc++-v3/include/std/ranges | 2 +-
1 file changed, 1 insertion(+
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
libstdc++-v3/ChangeLog:
* include/std/ranges (iota_view::operator+): Adjust definition
as per LWG 3580.
(iota_view::operator-): Likewise.
---
libstdc++-v3/include/std/ranges | 10 --
1 file c
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
after a while?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (viewable_range): Adjust as per
LWG 3481.
* testsuite/std/ranges/adaptors/all.cc (test07): New test.
---
libstdc++-v3/include/bits/
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and branches
after a while?
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::__iter_cat::_S_iter_cat): Adjust
criteria for returning bidirectional_iterator_tag as per LWG3535.
(join_view::_Iterator::_S_ite
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and branches?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (common_iterator::__arrow_proxy):
Make fully constexpr.
(common_iterator::__postfix_proxy): Likewise.
---
libstdc++-v3/include/bits/stl_iterator.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 11 after
a while?
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::base): Add forward_range
constraint as per LWG 3591.
(lazy_split_view::begin, lazy_split_view::end): Also check
simplene
Tested on x86_64-pc-linux-gnu, does this look ok for trunk/11/10?
PR libstdc++/102358
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (__niter_base): Make constexpr
for C++20.
(__miter_base): Likewise.
* testsuite/25_algorithms/move/constexpr.cc: New
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11/10?
libstdc++-v3/ChangeLog:
* include/std/ranges (istream_view): Replace this function
template with an alias template as per P2432R1.
(wistream_view): Define as per P2432R1.
(views::_Istream, views::ist
Here when checking for erroneous occurrences of 'auto' inside a template
argument (which is allowed by the concepts TS for class templates),
extract_autos_r picks up the CTAD placeholder for X{T{0}} which causes
check_auto_in_tmpl_args to reject this valid template argument. This
patch fixes this
In the testcase below the two left fold expressions each expand into a
logical expression with 1024 terms, for which potential_const_expr_1
takes more than a minute to return true. This is because p_c_e_1
performs trial evaluation of the first operand of a &&/|| in order to
determine whether to co
On Tue, 26 Oct 2021, Jason Merrill wrote:
> On Tue, Oct 26, 2021 at 2:46 PM Jakub Jelinek via Gcc-patches
> wrote:
> On Tue, Oct 26, 2021 at 01:44:18PM -0400, Patrick Palka via Gcc-patches
> wrote:
> > In the testcase below the two left fold expressions
On Tue, 26 Oct 2021, Jakub Jelinek wrote:
> On Tue, Oct 26, 2021 at 05:07:43PM -0400, Patrick Palka wrote:
> > The performance impact of the other calls to cxx_eval_outermost_const_expr
> > from p_c_e_1 is probably already mostly mitigated by the constexpr call
> > cache and the fact that we try t
On Wed, 27 Oct 2021, Jason Merrill wrote:
> On 10/27/21 14:54, Patrick Palka wrote:
> > On Tue, 26 Oct 2021, Jakub Jelinek wrote:
> >
> > > On Tue, Oct 26, 2021 at 05:07:43PM -0400, Patrick Palka wrote:
> > > > The performance impact of the other calls to
> > > > cxx_eval_outermost_const_expr
> >
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
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 de
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
> > a
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
expand_aggr_init_1
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
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 th
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 needed
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) deducti
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 libstdc+
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 libstdc+
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 _M_has_v
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 d
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 out-of-
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:
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
gcc/cp/Change
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 en
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 problema
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.
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 x86_64
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 d
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 x86_64
In passing, this also renames the template parameter _O2 to _Out2 in
ranges::partition_copy and uglify its function parameters out_true
and out_false.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk+branches?
PR libstdc++/101599
libstdc++-v3/ChangeLog:
* include/bits/
On Fri, 23 Apr 2021, Jason Merrill wrote:
> On 4/22/21 9:46 AM, Patrick Palka wrote:
> > On Wed, 21 Apr 2021, Patrick Palka wrote:
> >
> > > On Wed, 21 Apr 2021, Jason Merrill wrote:
> > >
> > > > On 4/12/21 1:20 PM, Patrick Palka wrote:
> > > > > Here we're crashing during deduction for a templ
During constexpr evaluation, a base-to-derived conversion may yield an
expression like (Derived*)(&D.2217.D.2106 p+ -4) where D.2217 is the
derived object and D.2106 is the base. But cxx_fold_indirect_ref
doesn't know how to resolve an INDIRECT_REF thereof to just D.2217,
because it doesn't handle
When substituting into the arguments of a base initializer pack
expansion, tsubst_initializer_list uses a dummy EXPR_PACK_EXPANSION
in order to expand an initializer such as Bases(args)... into
Bases#{0}(args#{0}) and so on. But when an argument inside the base
initializer is itself an pack expans
On Mon, 26 Apr 2021, Jason Merrill wrote:
> On 4/26/21 12:17 PM, Patrick Palka wrote:
> > During constexpr evaluation, a base-to-derived conversion may yield an
> > expression like (Derived*)(&D.2217.D.2106 p+ -4) where D.2217 is the
> > derived object and D.2106 is the base. But cxx_fold_indirec
Currently, the return type of this lambda is decltype(auto), so it ends
up returning a copy of _M_parent->_M_inner rather than a reference to it
when _S_ref_glvalue is false. Hence _M_inner and ranges::end(__inner_range)
are respectively an iterator and sentinel for different ranges, so
comparing
This fixes some bugs with our ranges algorithms in uncommon situations,
such as when the return type of a predicate is a non-copyable class type
that's implicitly convertible to bool (PR100187), when a comparison
predicate isn't invocable as an rvalue (PR100237), and when the return
type of a proje
This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right order instead of right-to-left order, in accordance with
DR 1227.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? [ diff generated with -w to hide noisy whitespace changes ]
Here, at template definition time, ordinary name lookup for 'foo(t)'
finds the deleted function, and so we form a CALL_EXPR thereof. Later
at instantiation time, when initially substituting into this CALL_EXPR
with T=N::A, we end up calling mark_used on this deleted function before
we augment the
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 accordance with
> > DR 1227.
> >
> > Bootstrapped and regtested on x86_64
This implements the wording changes of P2367R0 "Remove misuses of
list-initialization from Clause 24", modulo the parts that depend
on P1739R4 which we don't yet implement (due to LWG 3407).
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bit
This implements the wording changes of "join_view should join all views
of ranges".
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__non_propating_cache): Define
as per P2328.
(join_view): Remove constra
Tested on x86_64-pc-linux-gnu, committed as "obvious".
libstdc++-v3/ChangeLog:
* include/std/ranges (split_view::_InnerIter::operator++):
Depend on _Base instead of _Vp directly, as per LWG 3532.
---
libstdc++-v3/include/std/ranges | 2 +-
1 file changed, 1 insertion(+), 1 deleti
My r11-295 patch for PR68942 didn't consider that the callee of an
ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want
to disable mark_used when substituting into the template arguments of
this TEMPLATE_ID_EXPR because the arguments are clearly used regardless
of the outcome of
On Fri, 30 Apr 2021, Tim Song wrote:
> On Fri, Apr 30, 2021 at 12:11 PM Patrick Palka via Libstdc++
> wrote:
> >
> > + template
> > + _Tp&
> > + _M_emplace_deref(const _Iter& __i)
> > + {
> > + this->reset();
> > + return this->emplace(*__i);
> >
On Fri, 30 Apr 2021, Jonathan Wakely wrote:
> On 30/04/21 17:34 -0400, Patrick Palka via Libstdc++ wrote:
> > On Fri, 30 Apr 2021, Tim Song wrote:
> >
> > > On Fri, Apr 30, 2021 at 12:11 PM Patrick Palka via Libstdc++
> > > wrote:
> > > >
> > > > + template
> > > > + _Tp&
> > > > +
My r11-6815 change to defer access checking when processing a
base-clause removed a pair of pushclass / popclass calls that seemed to
be unnecessary now that we'd also defer access checking while parsing
the base-clause.
But it turns out this makes a difference in the below testcase, where we
have
This rewrites ranges::minmax and ranges::minmax_element so that it
performs at most 3*N/2 many comparisons, as required by the standard.
In passing, this also fixes PR100387 by avoiding a premature std::move
in ranges::minmax and in std::shift_right.
Tested on x86_64-pc-linux-gnu, does this look O
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
10/11?
libstdc++-v3/ChangeLog:
* include/std/ranges (transform_view::_Iterator::iter_swap):
Remove as per LWG 3520.
(join_view::_Iterator::iter_swap): Add indirectly_swappable
constraint as per
These constraints are already present on the template we're partially
specilalizing for.
[ This was recently fixed editorially in
https://github.com/cplusplus/draft/pull/4519 ]
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util
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 at most 3*N/2 many comparisons, as required by the standard.
> > In passing, this also fixes PR100387 by avoi
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 at most 3*N/2 many comparisons, as required by the standa
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/10/11?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterator::base): Make the
const& overload return a const reference and remove its
constraint as per LWG 3391. Make unconditionally noexcept.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/10/11?
libstdc++-v3/ChangeLog:
* include/std/ranges (filter_view::_Iterator::base): Make the
const& overload return a const reference and remove its
constraint as per LWG 3533. Make unconditionally noexcept.
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 entails.
In the testcase below, when generating the implicit deduction guide for
the constrained constructor te
This unconditionally enables the maybe_save_operator_binding mechanism
for all function templates, so that when resolving a dependent operator
expression from a function template we ignore later-declared
namespace-scope bindings that weren't visible at template definition
time. This patch addition
601 - 700 of 1378 matches
Mail list logo
