On Fri, 1 Dec 2023, Jason Merrill wrote:
> On 12/1/23 12:32, Patrick Palka wrote:
> > On Tue, 14 Nov 2023, Jason Merrill wrote:
> >
> > > On 11/14/23 11:10, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
&
On Thu, 30 Nov 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
> doesn't make sense for a lambda with an explicit object parameter. And it
> was never necessary, so let's
On Tue, 14 Nov 2023, Jason Merrill wrote:
> On 11/14/23 11:10, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > For decltype((x)) within a lambda where x
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Use the existing _Partial range adaptor closure object in the
definition of ranges::to instead of essentially open coding it.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_ToClosure): Replace with ...
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Jason Merrill wrote:
>
> > On 10/27/23 15:55, Patrick Palka wrote:
> > > With the previous two patches in place, we can now extend our
> > > deletedness diagnostic to note the ot
On Fri, 3 Nov 2023, Patrick Palka wrote:
> On Tue, 3 May 2022, Jason Merrill wrote:
>
> > On 5/2/22 14:50, Patrick Palka wrote:
> > > Currently when checking the constraints of a class template, we do so in
> > > the context of the template, not the specialized ty
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk?
-- >8 --
We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression. In passing
use STRIP_REFERENCE_REF consistently as well.
PR c++/112765
On Wed, 29 Nov 2023, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> Now that I'm posting this patch, I think you'll probably want me to use
> ba_any unconditionally. That works too; g++.dg/tc1/dr52.C just needs
> a trivial testsuite tweak:
> 'C' is not
On Thu, 23 Nov 2023, Jonathan Wakely wrote:
> Here's the finished version of the std::ranges::to patch, which I've
> pushed to trunk.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This adds the std::ranges::to functions for C++23. The rest of P1206R7
> is not yet implemented, i.e. the new
This adds a sanity check to cp_parser_expression_statement similar to
the one in finish_expr_stmt added by r6-6795-g0fd9d4921f7ba2, which
effectively downgrades accepts-invalid/wrong-code bugs like this one
into ice-on-invalid/ice-on-valid ones.
PR c++/112658
gcc/cp/ChangeLog:
*
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we deem the array-to-pointer conversions in both calls as invalid,
but we fail to issue a diagnostic for the second call, ultimately because
cp_build_c_cast doesn't replay errors from
On Fri, 24 Nov 2023, Patrick Palka wrote:
> On Wed, 22 Nov 2023, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > This patch implements C++23 class template argum
On Wed, 22 Nov 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> -- >8 --
>
> This patch implements C++23 class template argument deduction from
> inherited constructors, which is specified in terms of C++
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
A rewritten guide for alias CTAD isn't really a specialization of the
original guide, so we shouldn't register it as such. This avoids an ICE
in the below modules testcase which otherwise tries to inspect
On Thu, 23 Nov 2023, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu. I don't have write
> access.
>
> -- >8 --
>
> Otherwise attempting to get the originating module declaration ICEs
> because the DECL_CHAIN of an instantiated friend template is no longer
> its
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk/13?
-- >8 --
The entering_scope adjustment in tsubst_aggr_type assumes if an alias is
dependent, then so is the aliased type (and therefore it has template info)
but that's not true for the dependent alias template
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
This patch implements C++23 class template argument deduction from
inherited constructors, which is specified in terms of C++20 alias
CTAD which we already fully support. The rule for transforming
the
Tested on x86_64-pc-linux-gnu, pushed to trunk.
-- >8 --
Both of these PRs are fixed by r12-1403-gc4e50e500da7692a.
PR c++/98614
PR c++/104802
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/nontype-auto22.C: New test.
* g++.dg/cpp2a/concepts-partial-spec14.C: New
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12 (to match the PR107939 / r13-6525-ge09bc034d1b4d6 backports)?
-- >8 --
potential_constant_expression for a CALL_EXPR to a non-overload tests
FUNCTION_POINTER_TYPE_P on the callee rather than on the type of the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here we're ICEing from strip_typedefs for the partially instantiated
requires-expression when walking its REQUIRES_EXPR_EXTRA_ARGS since it's
a TREE_LIST with non-empty TREE_PURPOSE (to hold the captured
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The NON_DEPENDENT_EXPR removal exposed that is_direct_enum_init may end
up checking convertibility of a type-dependent argument.
PR c++/112515
gcc/cp/ChangeLog:
* decl.cc
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
require that the lambda has a capture default, unlike for decltype(x).
This patch fixes this inconsistency; I couldn't find a
On Fri, 10 Nov 2023, Jason Merrill wrote:
> On 11/10/23 10:28, Patrick Palka wrote:
> > On Fri, 10 Nov 2023, Patrick Palka wrote:
> >
> > > On Thu, 9 Nov 2023, Jason Merrill wrote:
> > >
> > > > On 11/8/23 16:59, Patrick Palka wrote:
> > >
On Fri, 10 Nov 2023, Jason Merrill wrote:
> On 11/10/23 12:25, Patrick Palka wrote:
> > On Thu, 9 Nov 2023, Jason Merrill wrote:
> >
> > > On 11/7/23 10:08, Patrick Palka wrote:
> > > > bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for
&
On Thu, 9 Nov 2023, Jason Merrill wrote:
> On 11/7/23 10:08, Patrick Palka wrote:
> > bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > In the COMPOUND_EXPR case of tsubst_expr, we were redundan
On Fri, 10 Nov 2023, Patrick Palka wrote:
> On Thu, 9 Nov 2023, Jason Merrill wrote:
>
> > On 11/8/23 16:59, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > trunk?
> > >
> > > -- >8 --
&
On Thu, 9 Nov 2023, Jason Merrill wrote:
> On 11/8/23 16:59, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > Here when building up the non-dependent .* expression, w
On Wed, 1 Nov 2023, Patrick Palka wrote:
> On Tue, 31 Oct 2023, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk? Does it look OK for release branches as well for sake of PR111703?
Pin
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13? (The
&& overloads are also missing on earlier branches, but I don't think
it makes a difference there since all uses of that operator* are on
lvalues before this fix.)
-- >8 --
We need to respect the value category of the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here when building up the non-dependent .* expression, we crash from
fold_convert on 'b.a' due to this (templated) COMPONENT_REF having an
IDENTIFIER_NODE instead of FIELD_DECL operand that middle-end
On Tue, 7 Nov 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> The capture decltype handling in finish_decltype_type wasn't looking
> through implicit INDIRECT_REF (added by convert_from_refer
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The capture decltype handling in finish_decltype_type wasn't looking
through implicit INDIRECT_REF (added by convert_from_reference), which
caused us to incorrectly resolve decltype((x)) to float& below.
We
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
We usually don't see capture proxies in finish_decltype_type because
process_outer_var_ref is a no-op inside an unevaluated context and
so a use of a capture inside decltype refers directly to the captured
bootstrapped and regtested on x86_64-pc-linxu-gnu, does this look OK for trunk?
-- >8 --
In the COMPOUND_EXPR case of tsubst_expr, we were redundantly clearing
the tf_decltype flag when substituting the LHS and also neglecting to
propagate it when substituting the RHS. This patch corrects this
yn Sat, 28 Oct 2023, Feng Jisen wrote:
> This patch remove a redundant partial specialization in class _Nth_type.
> For the original metafunction _Nth_type code,
> # 0
> template struct _Nth_type<0, _Tp0,
> _Rest...>
> { using type = _Tp0; };
> # 1
> template
> struct
On Tue, 3 May 2022, Jason Merrill wrote:
> On 5/2/22 14:50, Patrick Palka wrote:
> > Currently when checking the constraints of a class template, we do so in
> > the context of the template, not the specialized type. This is the best
> > we can do for a primary template
On Tue, 31 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk? Does it look OK for release branches as well for sake of PR111703?
>
> -- >8 --
>
> potential_constant_expression was incorrectly treating most l
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Does it look OK for release branches as well for sake of PR111703?
-- >8 --
potential_constant_expression was incorrectly treating most local
variables from a constexpr function as (potentially) constant because it
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Jason Merrill wrote:
>
> > On 10/27/23 15:55, Patrick Palka wrote:
> > > With the previous two patches in place, we can now extend our
> > > deletedness diagnostic to note the ot
On Fri, 27 Oct 2023, Jason Merrill wrote:
> On 10/27/23 15:55, Patrick Palka wrote:
> > With the previous two patches in place, we can now extend our
> > deletedness diagnostic to note the other considered candidates, e.g.:
> >
> >deleted16.C: In function 'int mai
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Patrick Palka wrote:
>
> > On Fri, 20 Oct 2023, Jason Merrill wrote:
> >
> > > Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't
> > > apply
> > > this sooner.
&
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 20 Oct 2023, Jason Merrill wrote:
>
> > Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't
> > apply
> > this sooner.
> >
> > -- 8< --
> >
> > In r13-3766 I changed
On Fri, 20 Oct 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't apply
> this sooner.
>
> -- 8< --
>
> In r13-3766 I changed the logic at the end of tourney to avoid redundant
> comparisons, but the change also meant skipping any less-good
New in patch 1/3:
* consistently use "non-viable" instead of "unviable"
throughout
* make 'champ' and 'challenger' in 'tourney' be z_candidate**
to simplify moving 'champ' to the front of the list. drive-by
cleanups in tourney, including renaming 'champ_compared_to_predecessor'
During overload resolution, we sometimes outright ignore a function in
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a template-id we discard all
non-template
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0);
| ~^~~
deleted16.C:5:6: note:
N.B. we currently don't diagnose 'new A(1)' below ultimately because
when in a template context our valid ctor call checking only happens for
type_build_ctor_call types.
-- >8 --
gcc/testsuite/ChangeLog:
* g++.dg/template/new14.C: New test.
---
gcc/testsuite/g++.dg/template/new14.C |
On Thu, 26 Oct 2023, Patrick Palka wrote:
> On Thu, 26 Oct 2023, Jason Merrill wrote:
>
> > On 10/25/23 14:55, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/25/23 14:55, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Now that we don't have to worry about looking thruogh NO
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/26/23 14:01, Patrick Palka wrote:
> > Since when in a template context we end up just discarding the result
> > of build_new_1, we don't have to bother with much of the code generation
> > it performs. This patch makes th
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Since when in a template context we end up just discarding the result
of build_new_1, we don't have to bother with much of the code generation
it performs. This patch makes the function exit early,
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
we can easily extend the -Wparentheses warning in convert_for_assignment
to consider (non-dependent) templated assignment operator
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Declaring get() inline seems necessary to avoid link failure:
/usr/bin/ld: /tmp/ccwdv6Co.o: in function `g3@pr105322.Decltype()':
decltype-1_b.C:(.text._ZW8pr105322W8Decltype2g3v[_ZW8pr105322W8Decltype2g3v]+0x18):
undefined
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
We also need to avoid folding 'outer_nelts_check' when in a template
context to prevent an ICE on the below testcase. This patch achieves
this by replacing the fold_build2 call with build2 (cp_fully_fold
On Tue, 24 Oct 2023, Jason Merrill wrote:
> On 10/24/23 13:03, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > like the right approach?
> >
> > -- >8 --
> >
> > This PR is another instance of NON_DEPEN
Tested on x86_64-pc-linux-gnu, pushed to trunk.
-- >8 --
We accept the non-dependent call f(e) here ever since the
NON_DEPENDENT_EXPR removal patch r14-4793-gdad311874ac3b3.
I haven't looked closely into why but I suspect wrapping 'e'
in a NON_DEPENDENT_EXPR was causing the argument conversion
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
like the right approach?
-- >8 --
This PR is another instance of NON_DEPENDENT_EXPR having acted as an
"analysis barrier" for middle-end routines, and now that it's gone we
may end up passing weird templated trees (that have a
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0);
| ~^~~
deleted16.C:5:6: note:
During overload resolution, we sometimes outright ignore a function from
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a template-id we discard all
non-template
The second patch in this series is new and ensures that the candidates
list isn't mysteriously missing some candidates when noting other
candidates due to deletedness.
-- >8 --
This patch:
* changes splice_viable to move the non-viable candidates to the end
of the list instead of removing
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
After the removal of NON_DEPENDENT_EXPR, cp_stabilize_reference which
used to just exit early for NON_DEPENDENT_EXPR is now more prone to
passing a weird templated tree to middle-end routines, which leads to
On Mon, 23 Oct 2023, Ken Matsui wrote:
> On Mon, Oct 23, 2023 at 10:05 AM Patrick Palka wrote:
> On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote:
> >
> > This patch optimizes the compilation performance of std::is_invocable
> > by dispatching t
On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_invocable
> by dispatching to the new __is_invocable built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_invocable): Use __is_invocable
>
On Sun, 22 Oct 2023, Ken Matsui wrote:
> Hi Patrick,
>
> There is an issue with the code in
> libstdc++-v3/include/bits/cpp_type_traits.h. Specifically, Clang 16
> does not accept the code, while Clang 17 does. Given that we aim to
> support the last two versions of Clang, we need to ensure that
Bootstrapped and regtested on x86_64-pc-linux-gnu, pushed to
trunk as obvious.
-- >8 --
After r14-4796-g3e3d73ed5e85e7, tsubst_copy_and_build (now named
tsubst_expr) no longer dispatches to tsubst for type trees, and
callers have to do it themselves if appropriate. This patch makes
some
On Fri, 20 Oct 2023, Patrick Palka wrote:
> On Fri, 20 Oct 2023, Patrick Palka wrote:
>
> > On Fri, 20 Oct 2023, Ken Matsui wrote:
> >
> > > This patch implements built-in trait for std::is_invocable.
> >
> > Nice! My email client unfortunately ate my
On Fri, 20 Oct 2023, Patrick Palka wrote:
> On Fri, 20 Oct 2023, Ken Matsui wrote:
>
> > This patch implements built-in trait for std::is_invocable.
>
> Nice! My email client unfortunately ate my first review attempt, so
> apologies for my brevity this time around.
&g
On Fri, 20 Oct 2023, Ken Matsui wrote:
> This patch implements built-in trait for std::is_invocable.
Nice! My email client unfortunately ate my first review attempt, so
apologies for my brevity this time around.
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_invocable.
> *
ed simultaneously after all :)
>
> nathan
>
> On 10/18/23 12:28, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > For a local variable initialized by a lambda:
> >
n traits.
> (cp_parser_trait): Handle cp_trait instead of enum rid.
> (cp_parser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
>
> Co-authored-by: Patrick Palka
> Signed-off-by: Ken Matsu
Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully).
-- >8 --
This patch removes stray NON_DEPENDENT_EXPR checks following the removal
of this tree code from the C++ FE. (Since this restores the build I
supppose it means the Rust FE never creates NON_DEPENDENT_EXPR trees in
the
Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully).
-- >8 --
This patch removes stray NON_DEPENDENT_EXPR checks following the removal
of this tree code from the C++ FE. (Since this restores the build I
supppose it means the Rust FE never creates NON_DEPENDENT_EXPR trees in
the
On Tue, 3 Oct 2023, David Malcolm wrote:
> As mentioned in my Cauldron talk, this patch adds a call to
> diagnostic_show_locus to the "required from here" messages
> in print_instantiation_partial_context_line, so that e.g., rather
> than the rather mystifying:
>
> In file included from
On Thu, 19 Oct 2023, Jason Merrill wrote:
> On 10/12/23 14:49, Patrick Palka wrote:
> > On Tue, 26 Sep 2023, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > for trunk?
> > >
> > > -- &
On Tue, 17 Oct 2023, Marek Polacek wrote:
> On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote:
> > On 10/16/23 20:39, Marek Polacek wrote:
> > > On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote:
> > > > On 10/13/23 14:53, Marek Polacek wrote:
> > > > > On Thu, Oct 12,
On Wed, 18 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
Note that this doesn't fix the other testcase in the PR, which doesn't use any
lambdas and which ICEs in the same way:
export module pr105322;
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For a local variable initialized by a lambda:
auto f = []{};
The corresponding BLOCK_VARS contains the variable declaration first,
followed by the closure type declaration, consistent with the
Handle cp_trait instead of enum rid.
> (cp_parser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
>
> Co-authored-by: Patrick Palka
> Signed-off-by: Ken Matsui
> ---
> gcc/c-family/c-common.cc |
On Mon, 16 Oct 2023, Ken Matsui wrote:
> On Mon, Oct 16, 2023 at 8:17 AM Patrick Palka wrote:
> >
> > On Sun, 15 Oct 2023, Ken Matsui wrote:
> >
> > > This patch sorts built-in traits alphabetically for better code
> > > readability.
> >
> >
On Mon, 16 Oct 2023, Ken Matsui wrote:
> On Mon, Oct 16, 2023 at 7:55 AM Patrick Palka wrote:
> >
> > On Sun, 15 Oct 2023, Ken Matsui wrote:
> >
> > > Since RID_MAX soon reaches 255 and all built-in traits are used
> > > approximately
> > > once i
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch optimizes the performance of the is_object trait by dispatching to
> the new __is_function and __is_reference built-in traits.
>
> libstdc++-v3/ChangeLog:
> * include/std/type_traits (is_object): Use __is_function and
>
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch implements built-in trait for std::is_arithmetic.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_arithmetic.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
> * semantics.cc (trait_expr_value):
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch optimizes the performance of the is_pointer trait by dispatching to
> the new __is_pointer built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/cpp_type_traits.h (__is_pointer): Use __is_pointer
> built-in trait.
>
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch sorts built-in traits alphabetically for better code
> readability.
Hmm, I'm not sure if we still want/need this change with this current
approach. IIUC gperf would sort the trait names when generating the
hash table code, and so we wanted a
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch accepts the use of built-in trait identifiers when they are
> actually not used as traits. Specifically, we check if the subsequent token
> is '(' for ordinary built-in traits or is '<' only for the special
> __type_pack_element built-in trait.
arser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
>
> Co-authored-by: Patrick Palka
> Signed-off-by: Ken Matsui
> ---
> gcc/c-family/c-common.cc | 7 --
> gcc/c-family/c-common.h | 5 -
On Sun, 15 Oct 2023, Ken Matsui wrote:
> On Sun, Oct 15, 2023 at 1:43 PM Patrick Palka wrote:
> >
> > On Fri, 13 Oct 2023, Ken Matsui wrote:
> >
> > > Since RID_MAX soon reaches 255 and all built-in traits are used
> > > approximately
> > > once i
built-in traits. Handle expression-yielding built-in traits.
> (cp_parser_trait): Handle cp_trait instead of enum rid.
> (cp_parser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
> * cp-trait-head.
On Tue, 26 Sep 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk?
>
> -- >8 --
>
> This follow-up patch removes some more repetition of the type-dependent
On second thought there's no good reason to split these pa
On Wed, 11 Oct 2023, Ken Matsui wrote:
> Since RID_MAX soon reaches 255 and all traits are used approximately once in
> a C++ translation unit, this patch instead uses only RID_TRAIT_EXPR and
> RID_TRAIT_TYPE for all traits and uses gperf to look up the specific trait.
>
>
On Tue, 10 Oct 2023, Ken Matsui wrote:
> Since RID_MAX soon reaches 255 and all traits are used approximately once in
> a C++ translation unit, this patch instead uses only RID_TRAIT_EXPR and
> RID_TRAIT_TYPE for all traits and uses gperf to look up the specific trait.
Nice! This looks good to
With the previous improvements in place, we can easily extend our
deletedness diagnostic to note the other candidates:
deleted16.C: In function ‘int main()’:
deleted16.C:10:4: error: use of deleted function ‘void f(int)’
10 | f(0);
| ~^~~
deleted16.C:5:6: note: declared
This patch:
* changes splice_viable to move the non-viable candidates to the end
of the list instead of removing them outright
* makes tourney move the best candidate to the front of the candidate
list
* adjusts print_z_candidates to preserve our behavior of printing only
viable
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
After the previous patch, we currently have two tsubst entry points
for expression trees: tsubst_copy_and_build and tsubst_expr. But the
latter is just a superset of the former that also handles statement
On Tue, 3 Oct 2023, Jason Merrill wrote:
> On 10/3/23 08:41, Patrick Palka wrote:
> > On Mon, 2 Oct 2023, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> >
On Mon, 2 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> The relationship between tsubst_copy_and_build and tsubst_copy (two of
> the main template argument substitution routi
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The relationship between tsubst_copy_and_build and tsubst_copy (two of
the main template argument substitution routines for expression trees)
is rather hazy. The former is mostly a superset of the latter,
On Tue, 26 Sep 2023, Jason Merrill wrote:
> On 9/25/23 16:43, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
> >
> > -- >8 --
> >
> > This tree code dates all the way back to r69130[1] whi
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
This follow-up patch removes some more repetition of the type-dependent
case of finish_call_expr, this time in of tsubst_copy_and_build. This
allows us to easily fix PR106086 -- which is about us failing to
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
In cp_parser_postfix_expression, we essentially repeat the
type-dependent and COMPONENT_REF callee cases of finish_call_expr.
This patch deduplicates this logic.
gcc/cp/ChangeLog:
* parser.cc
301 - 400 of 2236 matches
Mail list logo
