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
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] which implemented
typing of non-dependent expressions. Its motivation was never clear (to
me at least) since the documentation for it in e.g. cp-tree.def
This much more mechanical patch removes build_non_dependent_expr
(and make_args_non_dependent) and adjusts callers accordingly,
no functional change.
gcc/cp/ChangeLog:
* call.cc (build_new_method_call): Remove calls to
build_non_dependent_expr and/or make_args_non_dependent.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps backports?
-- >8 --
In order to compare the constraints of a ttp with that of its argument,
we rewrite the ttp's constraints in terms of the argument template's
template parameters. The substitution to
On Wed, 20 Sep 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> -- >8 --
>
> This fixes some missed SFINAE in grok_array_decl when checking a C++23
> multidimensional subscript operator expression.
>
On Wed, 20 Sep 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
... and perhaps 13?
>
> -- >8 --
>
> This fixes some missed SFINAE in grok_array_decl when checking a C++23
> multidimensional subscript operat
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
This fixes some missed SFINAE in grok_array_decl when checking a C++23
multidimensional subscript operator expression.
Note the existing pedwarn code paths are a backward compability fallback
for treating
On Tue, 19 Sep 2023, Patrick Palka wrote:
> On Tue, 19 Sep 2023, Jason Merrill wrote:
>
> > On 9/19/23 12:40, Patrick Palka wrote:
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
> >
> > OK for trunk. What's your argument for backpo
Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.
-- >8 --
Unlike DECL_TEMPLATE_INFO which is stored in DECL_LANG_SPECIFIC,
TYPE_TEMPLATE_INFO isn't stored in TYPE_LANG_SPECIFIC, so we don't
need to check for both in cxx_print_type. This fixes dumping the
template-info of ENUMERAL_TYPE
On Mon, 18 Sep 2023, Jason Merrill wrote:
> On 9/18/23 12:12, Patrick Palka wrote:
> > Jason pointed out that even implicit loads of volatile references need
> > to undergo lvalue-to-rvalue conversion, but we currently emit a warning
> > in this case and discard the load
On Tue, 19 Sep 2023, Jason Merrill wrote:
> On 9/19/23 12:40, Patrick Palka wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
>
> OK for trunk. What's your argument for backporting?
Thanks. I don't feel strongly about it, but I was thinking that sin
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
-- >8 --
1. Move class NTTP object pretty printing to a more general spot in
the pretty printer.
2. Print the type of an class NTTP object alongside its CONSTRUCTOR
value, like dump_expr would have done.
3. Don't pretty print
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
This patch makes tsubst_template_decl use use_spec_table=false also in
the non-class non-function template case, to avoid computing 'argvec' and
doing a hash table lookup from tsubst_decl (when partially
On Mon, Sep 18, 2023 at 9:36 AM Jason Merrill wrote:
>
> On 9/18/23 08:58, Patrick Palka wrote:
> > On Sun, 17 Sep 2023, Jason Merrill wrote:
> >
> >> On 9/17/23 15:13, Patrick Palka wrote:
> >>> Bootstrapped and regtested on x86_64-pc-linux
On Mon, 18 Sep 2023, Patrick Palka wrote:
> Jason pointed out that even implicit loads of volatile references need
> to undergo lvalue-to-rvalue conversion, but we currently emit a warning
> in this case and discard the load. This patch changes this behavior so
> that we don't iss
On Mon, 18 Sep 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> -- >8 --
>
> Here convert_to_void always completes the type of an indirection or
> id-expression, but according to [expr.context] an lvalu
Jason pointed out that even implicit loads of volatile references need
to undergo lvalue-to-rvalue conversion, but we currently emit a warning
in this case and discard the load. This patch changes this behavior so
that we don't issue a warning, and preserve the load.
gcc/cp/ChangeLog:
*
On Mon, 18 Sep 2023, Patrick Palka wrote:
> On Sun, 17 Sep 2023, Jason Merrill wrote:
>
> > On 9/16/23 17:41, Patrick Palka wrote:
> > > On Sat, 16 Sep 2023, Jason Merrill wrote:
> > >
> > > > On 9/15/23 12:03, Patrick Palka wrote:
> > > &g
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Here convert_to_void always completes the type of an indirection or
id-expression, but according to [expr.context] an lvalue-to-rvalue
conversion is applied to a discarded-value expression only if "the
301 - 400 of 2218 matches
Mail list logo
