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 fallback deleted operator()
overloads (as described
On Tue, 11 May 2021, Jonathan Wakely wrote:
> On 11/05/21 11:16 -0400, Patrick Palka via Libstdc++ wrote:
> > On Tue, 11 May 2021, Patrick Palka wrote:
> >
> > > floating_to_chars.cc includes the Ryu sources into an anonymous
> > > namespace as a convenient way to give all its symbols internal
On Tue, 11 May 2021, Patrick Palka wrote:
> floating_to_chars.cc includes the Ryu sources into an anonymous
> namespace as a convenient way to give all its symbols internal linkage.
> But an entity declared extern "C" always has external linkage, even
> from within an anonymous namespace, so this
floating_to_chars.cc includes the Ryu sources into an anonymous
namespace as a convenient way to give all its symbols internal linkage.
But an entity declared extern "C" always has external linkage, even
from within an anonymous namespace, so this trick doesn't work in the
presence of extern "C",
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
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
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.
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.
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
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
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:
*
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
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
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
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&
> > > >
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);
> >
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
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
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
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:
*
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
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
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 ]
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
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
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*)( p+ -4) where D.2217 is the
> > derived object and D.2106 is the base. But cxx_fold_indirect_ref
> >
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
During constexpr evaluation, a base-to-derived conversion may yield an
expression like (Derived*)( 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
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
We correctly diagnose the invalid access since r11-1350.
gcc/testsuite/ChangeLog:
PR c++/16617
* g++.dg/template/access36.C: New test.
---
gcc/testsuite/g++.dg/template/access36.C | 25
1 file changed, 25 insertions(+)
create mode 100644
We correctly accept this testcase since r11-1638.
gcc/testsuite/ChangeLog:
PR c++/84689
* g++.dg/cpp0x/sfinae67.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/sfinae67.C | 20
1 file changed, 20 insertions(+)
create mode 100644
As described in detail in comment #4 of this PR, when tentatively
parsing a construct that can either be a type or an expression, if
during the type parse we encounter an unexpected template placeholder,
we need to simulate an error rather than issue a real error because the
subsequent expression
This implements the wording changes of CWG2374, which clarifies the
wording of P0138 to forbid e.g. direct-list-initialization of a scoped
enumeration from a different scoped enumeration.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
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 template placeholder from a
> > > dependent initializer because one of the initializer's elements has an
> > >
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 template placeholder from a
> > dependent initializer because one of the initializer's elements has an
> > empty TREE_TYPE, something which resolve_args and later
On Mon, 12 Apr 2021, Patrick Palka wrote:
> Here we're crashing during deduction for a template placeholder from a
> dependent initializer because one of the initializer's elements has an
> empty TREE_TYPE, something which resolve_args and later unify_one_argument
> don't expect. And if the
On Tue, 20 Apr 2021, Jonathan Wakely wrote:
> On 19/04/21 22:25 -0400, Patrick Palka via Libstdc++ wrote:
> > This implements the wording changes of P2259R1 "Repairing input range
> > adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408.
> >
> > The wording changes are
This implements the wording changes of P2259R1 "Repairing input range
adaptors and counted_iterator", which resolves LWG 3283, 3289 and 3408.
The wording changes are relatively straightforward, but they require
some boilerplate to implement: the changes to make a type alias
"conditionally
When pretty printing a function pointer type via
pp_cxx_parameter_declaration_clause, we end up always printing an empty
parameter list because the loop that's supposed to print the parameter
list iterates over 'args' instead of 'types', and 'args' is empty in
this case when a FUNCTION_TYPE is
Here, reduced_constant_expression_p is incorrectly returning true for a
partially initialized array CONSTRUCTOR, because when the
CONSTRUCTOR_NO_CLEARING flag is set the predicate doesn't check that
every array element is initialized by the CONSTRUCTOR, it just checks
that every initializer within
In the testcase ref11.C below, during deduction for the call f(a),
uses_deducible_template_parms returns false for the dependent
specialization A because V is wrapped in an implicit INDIRECT_REF
(formed from template_parm_to_arg), and this causes unify_one_argument
to exit early, causing deduction
On Tue, 13 Apr 2021, Jason Merrill wrote:
> On 4/13/21 8:41 AM, Jason Merrill wrote:
> > On 4/12/21 6:24 PM, Patrick Palka wrote:
> > > On Mon, 12 Apr 2021, Jason Merrill wrote:
> > >
> > > > On 4/10/21 3:57 PM, Patrick Palka wrote:
> > > > > Here, in C++17 mode, we only pedwarn about the use of
On Mon, 12 Apr 2021, Jason Merrill wrote:
> On 4/10/21 3:57 PM, Patrick Palka wrote:
> > Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
> > then later ICE from alias_ctad_tweaks when attempting to add a
> > constraint to one of the guides. Since the construction of the
Here we're crashing during deduction for a template placeholder from a
dependent initializer because one of the initializer's elements has an
empty TREE_TYPE, something which resolve_args and later unify_one_argument
don't expect. And if the deduction from a dependent initializer
otherwise fails,
According to [temp.concept]/6 and [temp.pre]/9, a concept definition and
a requires clause are both unevaluated contexts, and hence satisfaction
deals only with unevaluated operands, so we should set cp_unevaluated
in these three situations.
(I guess we should set cp_unevaluated during
Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
then later ICE from alias_ctad_tweaks when attempting to add a
constraint to one of the guides. Since the construction of the guides
of an alias template effectively relies on concepts, we shouldn't be
permissive about alias
do_class_deduction handles specially the case where we're deducing one
placeholder from another equivalent one, but here the initializer passed
to do_class_deduction is wrapped in an EXPR_PACK_EXPANSION (we're being
called from unify during get_partial_spec_bindings). This patch makes
We accept this testcase after r11-7985.
gcc/testsuite/ChangeLog:
PR c++/90215
* g++.dg/cpp1z/fold-lambda4.C: New test.
---
gcc/testsuite/g++.dg/cpp1z/fold-lambda4.C | 30 +++
1 file changed, 30 insertions(+)
create mode 100644
On Thu, 8 Apr 2021, Jason Merrill wrote:
> On 4/7/21 12:10 PM, Patrick Palka wrote:
> > We currently substitute through a lambda's constraints whenever we
> > regenerate it via tsubst_lambda_expr. This is the wrong approach
> > because it can lead to hard errors due to constraints being
On Thu, 8 Apr 2021, Marek Polacek via Gcc-patches wrote:
> When we have a member function with auto parameter like this:
>
> struct S {
> void f(auto);
> };
>
> cp_parser_member_declaration -> grokfield produces a FUNCTION_DECL
> "void S::foo(auto:1)", and then
This works around the remaining reported execution FAILs of this test on
AIX, Solaris and Darwin. Eventually we should rewrite this test to be
less fragile, but there's not enough time to do that for GCC 11.
Tested on AIX, Solaris and x86_64-pc-linux-gnu, committed to trunk as
"obvious".
In the testcase below, we're crashing during constraint checking of the
implicitly generated deduction guides for the nested class template A::B
because we never substitute the outer template arguments (for A) into
the constraint, neither ahead of time nor as part of satisfaction.
Ideally we'd
We currently substitute through a lambda's constraints whenever we
regenerate it via tsubst_lambda_expr. This is the wrong approach
because it can lead to hard errors due to constraints being evaluated
out of order (as in the testcase concepts-lambda17.C below), and because
it doesn't mesh well
On Mon, 5 Apr 2021, Patrick Palka wrote:
> In this PR, we're crashing because the constraint handling inside
> do_auto_deduction doesn't expect to see an adc_decomp_type context.
> This patch fixes this by treating adc_decomp_type like adc_variable_type
> and adc_return_type during the constraint
In this PR, we're crashing because the constraint handling inside
do_auto_deduction doesn't expect to see an adc_decomp_type context.
This patch fixes this by treating adc_decomp_type like adc_variable_type
and adc_return_type during the constraint handling.
Meanwhile, I noticed we weren't
On Fri, 26 Mar 2021, Nathan Sidwell wrote:
>
> During development of modules, I had difficulty deciding whether the
> module
> flags of a template should live on the decl_template_result, the
> template_decl, or both. I chose the latter, and require them to be
> consistent. This and a
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.
We could
In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.
AFAICT 'type' will always be a bare 'auto' in the CTAD case, so we don't
need to look deeply to
When checking dependence of a placeholder type constraint, if the first
template argument of the constraint is an argument pack, we need to
expand it so that we properly separate the implicit 'auto' argument from
the rest.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
We currently mangle __alignof__ as a vendor extended operator,
but that's problematic for the reasons mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6.
This patch changes the mangling of __alignof__ to instead use the
new "vendor extended expression" syntax that's proposed in
On Mon, 29 Mar 2021, Patrick Palka wrote:
> The header currently copies some simple algorithms from
> , which was originally done in order to avoid a
> circular dependency with the header. This is no longer an issue since
> the latter header now includes instead of all of
> .
>
> This means
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find): Define.
(split_view::_OuterIter::operator++): Apply proposed resolution
of LWG 3505.
* testsuite/std/ranges/adaptors/split.cc (test10): New test.
---
libstdc++-v3/include/std/ranges | 28
The header currently copies some simple algorithms from
, which was originally done in order to avoid a
circular dependency with the header. This is no longer an issue since
the latter header now includes instead of all of
.
This means we could now just include and remove the
copied
While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use this concept in its constraints. Add
missing private
On Sun, 28 Mar 2021, Patrick Palka wrote:
> This rewrites our range adaptor implementation for more comprehensible
> error messages, improved SFINAE behavior and conformance to P2281.
>
> The diagnostic improvements mostly comes from using appropriately named
> functors instead of lambdas in the
This rewrites our range adaptor implementation for more comprehensible
error messages, improved SFINAE behavior and conformance to P2281.
The diagnostic improvements mostly comes from using appropriately named
functors instead of lambdas in the generic implementation of partial
application and
This implements operator++, operator-- and operator<=> for the
integer-class types defined in max_size_type.h, which I overlooked
when originally implementing the class.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/max_size_type.h
This implements a minimal integer class type that emulates 128-bit
unsigned arithmetic using a pair of 64-bit integers, which the
floating-point std::to_chars implementation then uses as a drop-in
replacement for unsigned __int128 on targets that lack the latter.
This allows us to fully support
This makes Ryu consistently use the uint128_t alias defined in
floating_to_chars.cc.
libstdc++-v3/ChangeLog:
* src/c++17/ryu/LOCAL_PATCHES: Update.
* src/c++17/ryu/d2s_intrinsics.h: Don't define uint128_t.
* src/c++17/ryu/generic_128.h: Likewise.
*
This file keeps track of the local modifications we've made to our copy
of Ryu.
libstdc++-v3/ChangeLog:
* src/c++17/ryu/LOCAL_PATCHES: New file.
---
libstdc++-v3/src/c++17/ryu/LOCAL_PATCHES | 1 +
1 file changed, 1 insertion(+)
create mode 100644
Since Ryu has an alias uint128_t for this same purpose, it seems best
for us to use this name as well, so as to minimize the amount of local
modifications we'd need to make to our copy of Ryu. (In a subsequent
patch, we're going to remove Ryu's aliases so that it uses the one
defined in
On Fri, 5 Mar 2021, Jason Merrill wrote:
> On 3/5/21 1:05 PM, Patrick Palka wrote:
> > Here, during cxx_eval_increment_expression (with lval=false) of
> > ++__first where __first is &"mystr"[0], we correctly update __first
> > to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
> >
On Fri, 5 Mar 2021, Jason Merrill wrote:
> On 3/4/21 9:55 PM, Patrick Palka wrote:
> > On Thu, 4 Mar 2021, Patrick Palka wrote:
> >
> > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > >
> > > > On Thu, 4 Mar 2021, Jason Merrill wrote:
> > > >
> > > > > On 3/4/21 11:32 AM, Patrick Palka wrote:
>
Here, during cxx_eval_increment_expression (with lval=false) of
++__first where __first is &"mystr"[0], we correctly update __first
to &"mystr"[1] but we end up returning &"mystr"[0] + 1 instead of
&"mystr"[1]. This unreduced return value inhibits other pointer
arithmetic folding during later
This makes tsubst_copy appropriately handle a variable template-id, which
in turn fixes tsubsting a COMPONENT_REF whose member operand is known at
parse time to be a variable template-id, as in the initialization of 'x'
in the first testcase. Previously, we rejected this testcase with the
error
On Thu, 4 Mar 2021, Patrick Palka wrote:
> On Thu, 4 Mar 2021, Patrick Palka wrote:
>
> > On Thu, 4 Mar 2021, Jason Merrill wrote:
> >
> > > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > > >
> > > > > My recent r11-7454 changed the way
On Thu, 4 Mar 2021, Patrick Palka wrote:
> On Thu, 4 Mar 2021, Jason Merrill wrote:
>
> > On 3/4/21 11:32 AM, Patrick Palka wrote:
> > > On Thu, 4 Mar 2021, Patrick Palka wrote:
> > >
> > > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > > placeholders during
On Thu, 4 Mar 2021, Jason Merrill wrote:
> On 3/4/21 11:32 AM, Patrick Palka wrote:
> > On Thu, 4 Mar 2021, Patrick Palka wrote:
> >
> > > My recent r11-7454 changed the way do_auto_deduction handles constrained
> > > placeholders during template argument deduction (context == adc_unify)
> > >
On Thu, 4 Mar 2021, Patrick Palka wrote:
> My recent r11-7454 changed the way do_auto_deduction handles constrained
> placeholders during template argument deduction (context == adc_unify)
> when processing_template_decl != 0.
>
> Before the patch, when processing_template_decl != 0 we would
My recent r11-7454 changed the way do_auto_deduction handles constrained
placeholders during template argument deduction (context == adc_unify)
when processing_template_decl != 0.
Before the patch, when processing_template_decl != 0 we would just
ignore the constraints on the placeholder in this
On Wed, 3 Mar 2021, Moritz Sichert via Libstdc++ wrote:
> std::ranges::reverse_view uses make_reverse_iterator in its
> implementation as described in [range.reverse.view]. This accidentally
> allows ADL as an unqualified name is used in the call. According to
> [contents], however, this should
On Tue, 2 Mar 2021, Jason Merrill wrote:
> On 3/2/21 11:45 AM, Patrick Palka wrote:
> > On Mon, 1 Mar 2021, Jason Merrill wrote:
> >
> > > On 2/28/21 12:59 PM, Patrick Palka wrote:
> > > > This folds the diagnose_requires_expr routines into the corresponding
> > > > tsubst_requires_expr ones.
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:59 PM, Patrick Palka wrote:
> > This folds the diagnose_requires_expr routines into the corresponding
> > tsubst_requires_expr ones. This is achieved by making the latter
> > routines take a sat_info instead of a subst_info, and assigning
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:58 PM, Patrick Palka wrote:
> > This patch mostly performs some straightforward refactoring:
> >
> >- Renamed satisfy_constraint to satisfy_normalized_constraints
> >- Renamed the three-parameter version of
On Mon, 1 Mar 2021, Jason Merrill wrote:
> On 2/28/21 12:40 PM, Patrick Palka wrote:
> > On Fri, 12 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/10/21 9:41 AM, Patrick Palka wrote:
> > > > On Tue, 9 Feb 2021, Jason Merrill wrote:
> > > >
> > > > > On 2/8/21 2:03 PM, Patrick Palka wrote:
> > >
This folds the diagnose_requires_expr routines into the corresponding
tsubst_requires_expr ones. This is achieved by making the latter
routines take a sat_info instead of a subst_info, and assigning the
appropriate meanings to the flags sat_info::noisy and
sat_info::diagnose_unsatisfaction_p
This patch mostly performs some straightforward refactoring:
- Renamed satisfy_constraint to satisfy_normalized_constraints
- Renamed the three-parameter version of satisfy_constraint_expression
to satisfy_nondeclaration_constraints
- Removed normalize_(non)?template_requirements
-
On Fri, 12 Feb 2021, Jason Merrill wrote:
> On 2/11/21 5:14 PM, Patrick Palka wrote:
> > On Thu, 11 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/8/21 2:03 PM, Patrick Palka wrote:
> > > > This fixes the way we check satisfaction of constraints on placeholder
> > > > types in various contexts,
On Fri, 12 Feb 2021, Jason Merrill wrote:
> On 2/10/21 9:41 AM, Patrick Palka wrote:
> > On Tue, 9 Feb 2021, Jason Merrill wrote:
> >
> > > On 2/8/21 2:03 PM, Patrick Palka wrote:
> > > > This sets up the functionality for controlling the initial set of
> > > > template parameters to pass to
On Tue, 9 Feb 2021, Patrick Palka wrote:
> When an abbreviated function template has a complex placeholder return
> type such auto& or auto**, the level adjustment performed by
> splice_late_return_type directly replaces the 'auto' inside the original
> return type with the level-adjusted 'auto',
On Thu, 25 Feb 2021, Jason Merrill wrote:
> On 2/25/21 1:37 AM, Patrick Palka wrote:
> > In-Reply-To: <20210225063712.3725111-1-ppa...@redhat.com>
>
> BTW, This patch doesn't seem in any way a reply to your previous patch, so
> it's confusing for the mail headers (and thus MUA threading) to say
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' doesn't correspond with
the augmented template arguments 'args', and so the instantiation
context that we push via push_tinst_level isn't quite correct. This
manifests as
My r10-7705 patch for PR94521 made us set TFF_NO_FUNCTION_ARGUMENTS when
pretty printing the function scope of a local class type in order to
eliminate infinite recursion with a function signature that contains
decltype([]{}). But due to the way dump_function_decl works, this
change regressed our
The code path in __floating_to_chars_precision for handling long double
by going through printf now also handles __float128, so the condition
that guards this code path needs to be updated accordingly.
Tested on x86_64-pc-linux-gnu (i.e. it compiles :)), does this look OK
for trunk?
On Wed, 24 Feb 2021, Jonathan Wakely wrote:
> On 23/02/21 11:30 -0500, Patrick Palka via Libstdc++ wrote:
> > On Mon, 22 Feb 2021, Patrick Palka wrote:
> >
> > > This makes the hexadecimal section of the long double std::to_chars
> > > testcase more robust by avoiding false-negative FAILs due to
On Mon, 22 Feb 2021, Patrick Palka wrote:
> This makes the hexadecimal section of the long double std::to_chars
> testcase more robust by avoiding false-negative FAILs due to printf
> using a different leading hex digit than us, and by additionally
> verifying the correctness of the hexadecimal
This makes the hexadecimal section of the long double std::to_chars
testcase more robust by avoiding false-negative FAILs due to printf
using a different leading hex digit than us, and by additionally
verifying the correctness of the hexadecimal form via round-tripping
through std::from_chars.
The logic in std::to_chars for extracting the high- and low-order parts
of a IBM long double value does the right thing on powerpc64le, but not
on powerpc64be. This patch makes the extraction endian-agnostic, which
fixes the execution FAIL of to_chars/long_double.cc on powerpc64be.
Tested on
My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION
(mimicking build_target_expr) causes the debuginfo regression PR96997.
Given that this change is mostly independent of the rest of the commit,
and that the only fallout of reverting it is a less accurate error
message location in
When determining whether to rule out initializer-list constructors
during CTAD with a single-element initializer list, the element type's
cv-qualifiers should be irrelevant. This patch fixes this by making
is_spec_or_derived strip cv-qualifiers from the supplied expression
type.
In passing, I
901 - 1000 of 1377 matches
Mail list logo
