> Any progress on this, or do I need to coax the process along? :)
Yeah, I've been working on it since the copyright assignment process
has finished, originally I was going to note that on my next update
which I had hoped to finish today or tomorrow. Well, in truth I was
hoping to send one the sa
> > I will try to get something done today, but I was struggling with
> > writing some of the tests, there's also a lot more of them now. I also
> > wrote a bunch of musings in comments that I would like feedback on.
> >
> > My most concrete question is, how exactly should I be testing a
> > pedwa
> (Jakub)
> There are different kinds of format strings in GCC, the most common
> are the gcc-internal-format strings. If you call a function which
> is expected to take such translatable format string (in particular
> a function which takes a gmsgid named argument like error, error_at,
> pedwarn,
> No, that wouldn't be appropriate for translation.
> None of non-member, static member and explicit object member are
> something that should be printed verbatim untranslated.
> "%s function %qD cannot have cv-qualifier", _("non-member")
> etc. is still inappropriate, some language might need to r
> A BASELINK expresses the result of name lookup for a member function,
> since we need to pass information about the name lookup context along to
> after overload resolution.
>
> An OFFSET_REF (with PTRMEM_OK_P) is used to express that we saw the
> &A::f syntax, so we could build a pointer to m
> (waffl3x (me))
> At a glance it seems like all I need to do then is disable the
> PTRMEM_OK_P flag then.
I'm just now realizing that I'm almost certainly wrong about this. It
still needs PTRMEM_OK_P set if there are any implicit-object member
functions in the overlo
> >
> > Based on what you've said, I assume that OFFSET_REF handles static
> > member functions that are overloaded. But as I've said this seems to
> > contradict the comments I'm reading, so I'm not sure that I'm
> > understanding you correctly.
>
>
> That's right. For instance,
>
> struct A {
t = TREE_OPERAND (arg, 1);
if (TYPE_REF_P (TREE_TYPE (t)))
{
if (complain & tf_error)
error_at (loc,
"cannot create pointer to reference member %qD", t);
return error_mark_node;
}
/* -- Waffl3x
to a non-static data member
> into a pointer-to-member. */ { tree type; tree t; gcc_assert (PTRMEM_OK_P
> (arg)); t = TREE_OPERAND (arg, 1); if (TYPE_REF_P (TREE_TYPE (t))) { if
> (complain & tf_error) error_at (loc, "cannot create pointer to reference
> member %qD&quo
Just want to quickly check, when is the cutoff for GCC14 exactly? I
want to know how much time I have left to try to tackle this bug with
subscript. I'm going to be crunching out final stuff this week and I'll
try to get a (probably non-final) patch for you to review today.
Alex
--
On Wednesday, November 1st, 2023 at 5:15 PM, waffl3x
wrote:
>
>
> Just want to quickly check, when is the cutoff for GCC14 exactly? I
> want to know how much time I have left to try to tackle this bug with
> subscript. I'm going to be crunching out final stuff this wee
> > That leaves 2, 4, and 5.
> >
> > 2. I am pretty sure xobj functions should have the struct they are a
> > part of recorded as the method basetype member. I have already checked
> > that function_type and method_type are the same node type under the
> > hood and it does appear to be, so it shou
I'm unfortunately going down a rabbit hole again.
--function.h:608
```
/* If pointers to member functions use the least significant bit to
indicate whether a function is virtual, ensure a pointer
to this function will have that bit clear. */
#define MINIMUM_METHOD_BOUNDARY \
((TARGET_PTRM
lly uncertain if I'm writing them properly.
Alex
From e730dcba51503446cc362909fcab19361970b448 Mon Sep 17 00:00:00 2001
From: waffl3x
Date: Sat, 4 Nov 2023 05:35:10 -0600
Subject: [PATCH 1/2] c++: Initial support for C++23 P0847R7 (Deducing this)
[PR102609]
This patch implements initial
p and go
to bed. I am very happy to be getting close to a final product here.
Hopefully if all goes well I'll be able to fit in the final missing
features before feature lock hits.
AlexFrom c8e8155a635fab7f326d0ad32326da352d7c323e Mon Sep 17 00:00:00 2001
From: waffl3x
Date: Sun, 5 Nov 20
On Tuesday, January 9th, 2024 at 3:52 PM, Jason Merrill
wrote:
>
>
> On 1/9/24 17:34, waffl3x wrote:
>
> > On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill ja...@redhat.com
> > wrote:
> >
> >
> > Is the type of an implicit ob
Bootstrapped and tested on x86_64-linux with no regressions.
I'm still getting used to things so let me know if the change log
entries are excessive, thanks.From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Thu, 11 Jan 2024 14:32:46 -0700
Subject: [
int n = 0;
auto f = [](this Self){
static_assert(__is_same (decltype(n), int));
decltype((n)) a; // { dg-error {is not captured} }
};
f();
Could you clarify if this error being removed was intentional. I do
recall that Patrick Palka wanted to remove this error in his patch, but
i
On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill
wrote:
>
>
> On 12/22/23 04:01, waffl3x wrote:
>
> > int n = 0;
> > auto f = [](this Self){
> > static_assert(__is_same (decltype(n), int));
> > decltype((n)) a; // { dg-error {is not captured}
the current wording.
Alex
On Tuesday, December 26th, 2023 at 9:37 AM, Jason Merrill
wrote:
>
>
> On 12/23/23 02:10, waffl3x wrote:
>
> > On Friday, December 22nd, 2023 at 10:26 AM, Jason Merrill ja...@redhat.com
> > wrote:
> >
> > > On 12/22/
now.
Some days feel really unproductive when the majority is investigation
and thinking. This was one of them, but at least I'm confident that my
conclusions are correct. Aren't edge cases fun?
Alex
On Monday, January 1st, 2024 at 8:17 AM, waffl3x wrote:
>
>
> I've bee
bj
member functions assuming that iobj member functions introduced by
using declarations are handled properly. I think that's the best option
for my patch right now.
Well that investigation took the majority of my day. I'm just glad I'm
certain of what direction to take now.
Al
me changes
so you will have to look over it quickly but hopefully it will be split
up enough to make that convenient.
Alex
On Monday, January 1st, 2024 at 10:12 AM, waffl3x
wrote:
>
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
>
> I've posted the report here,
t's all, hopefully all is good, fingers crossed.
AlexFrom cd122053dfad741a7d90adcd45929af768ce643f Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Sun, 31 Dec 2023 03:16:36 -0700
Subject: [PATCH 1/4] C++23 P0847R7 (deducing this) - prerequisite changes.
[PR102609]
Adds the xobj_flag member
Bootstrapped and tested on x86_64-linux with no regressions.From 32a713d9826a042b260e84dcfbfd31c619a122fb Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Fri, 5 Jan 2024 14:34:34 -0700
Subject: [PATCH 3/4] C++23 P0847R7 (deducing this) - diagnostics. [PR102609]
Diagnostics for xobj member functions
Bootstrapped and tested on x86_64-linux with no regressions.
That's it for now. If I manage to finish CWG2586 in time I guess I'll
submit it as patch 5/4? I'm definitely locked in on all these changes
unless there's a really good reason.
Alex
On Saturday, January 6th, 2024 at 5:17 PM, Jakub Jelinek
wrote:
>
>
> On Sun, Jan 07, 2024 at 12:05:50AM +, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > That's it for now. If I manage to finish CWG2586
Bootstrapped and tested on x86_64-linux with no regressions.
Not as hard as I thought it would be! As noted in the commit message, I believe
this makes explicit object member functions feature complete.From a5f947d411b5e19ce7efbb4d766a2792b02c9626 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Sun
On Tuesday, January 9th, 2024 at 1:58 PM, Jason Merrill
wrote:
>
>
> On 1/6/24 19:00, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > I'm considering this finished, I have CWG2586 working but I have not
> >
On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill
wrote:
>
>
> On 1/9/24 15:58, Jason Merrill wrote:
>
> > On 1/6/24 19:00, waffl3x wrote:
> >
> > > Bootstrapped and tested on x86_64-linux with no regressions.
> > >
> > > I&
I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure by the literal wording of the standard, this is well formed.
template
concept Constrain = true;
struct S {
void f(this auto, Constrain auto) {};
On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill
wrote:
>
>
> On 12/1/23 01:02, waffl3x wrote:
>
> > I ran into another issue while devising tests for redeclarations of
> > xobj member functions as static member functions and vice versa. I am
> &
On Monday, December 4th, 2023 at 9:39 PM, waffl3x
wrote:
> On Monday, December 4th, 2023 at 9:35 PM, waffl3x waff...@protonmail.com
> wrote:
>
>
>
> > > > @@ -15402,6 +15450,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t
> > > > co
On Monday, December 4th, 2023 at 9:35 PM, waffl3x
wrote:
>
>
> >> @@ -15402,6 +15450,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t
> >> complain,
>
> > > gcc_checking_assert (TYPE_MAIN_VARIANT (TREE_TYPE (ve))
> > > == TYPE_MAIN_VARI
>> @@ -15402,6 +15450,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t
>> complain,
>> gcc_checking_assert (TYPE_MAIN_VARIANT (TREE_TYPE (ve))
>>== TYPE_MAIN_VARIANT (type));
>> SET_DECL_VALUE_EXPR (r, ve);
>> +
Does CWG2834 effect this weird edge case? I couldn't quite grasp the
standardese so I'm not really sure. These are a few cases from a test
that I finalized last night. I ran this by jwakely and he agreed that
the behavior as shown is correct by the standard. I'll also add that
this is also the curr
On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill
wrote:
>
>
> On 12/5/23 23:23, waffl3x wrote:
>
> > Does CWG2834 effect this weird edge case?
>
>
> 2834 affects all partial ordering with explicit object member functions;
Both in relation to each ot
On Wednesday, December 6th, 2023 at 1:48 AM, Jakub Jelinek
wrote:
>
>
> On Wed, Dec 06, 2023 at 07:33:21AM +, waffl3x wrote:
>
> > Here is the next version, it feels very close to finished. As before, I
> > haven't ran a bootstrap or the full te
Follow up to this, bootstrapped and tested with no regressions.
On Wednesday, December 6th, 2023 at 12:33 AM, waffl3x
wrote:
>
>
> Here is the next version, it feels very close to finished. As before, I
> haven't ran a bootstrap or the full testsuite yet but I did run t
On Friday, December 8th, 2023 at 12:25 PM, Jason Merrill
wrote:
>
>
> On 12/6/23 02:33, waffl3x wrote:
>
> > Here is the next version, it feels very close to finished. As before, I
> > haven't ran a bootstrap or the full testsuite yet but I did run the
> >
I noticed I made a bit of a mistake in grokdeclarator:find_xobj_parm,
this code:
```
if (!parm_list || parm_list == void_list_node)
return false;
if (TREE_PURPOSE (parm_list) != this_identifier)
return false;
```
Can be simplified to this code:
```
if (!parm_list || TREE_PURPOSE (parm_list) !=
I guess I'll be attaching all new e-mails here.
I found a new, kinda scary issue.
```
bool
start_preparsed_function (tree decl1, tree attrs, int flags)
{
tree ctype = NULL_TREE;
bool doing_friend = false;
/* Sanity check. */
gcc_assert (VOID_TYPE_P (TREE_VALUE (void_list_node)));
gcc_
> > I'm unfortunately going down a rabbit hole again.
> >
> > --function.h:608
> > `/* If pointers to member functions use the least significant bit to
> > indicate whether a function is virtual, ensure a pointer to this function
> > will have that bit clear. */ #define MINIMUM_METHOD_BOUNDARY
I
think I should just revise this patch with everything else.
On Thursday, November 9th, 2023 at 2:53 PM, Jason Merrill
wrote:
>
>
> On 11/5/23 10:06, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > I originally th
> > I had wanted to write about some of my frustrations with trying to
> > write a test for virtual specifiers and errors/warnings for
> > shadowing/overloading virtual functions, but I am a bit too tired at
> > the moment and I don't want to delay getting this up for another night.
> > In short, t
> [combined reply to all three threads]
>
> On 11/9/23 23:24, waffl3x wrote:
>
> > > > I'm unfortunately going down a rabbit hole again.
> > > >
> > > > --function.h:608
> > > > `/* If pointers to member functions use the least s
Just a quick addition here as I was starting to work on things I
realized where some misunderstandings were coming from. (Please also
see my previous e-mail, it is all still relevant, I just wanted to
clarify this.)
(From the other thread)
> > @@ -9949,7 +9951,8 @@ build_over_call (struct z_candid
On Monday, November 13th, 2023 at 8:48 PM, Jason Merrill
wrote:
>
>
> On 11/11/23 05:43, waffl3x wrote:
>
> > > [combined reply to all three threads]
> > >
> > > On 11/9/23 23:24, waffl3x wrote:
> > >
> > > > > &
The patch is coming along, I just have a quick question regarding
style. I make use of IILE's (immediately invoked lambda expression) a
whole lot in my own code. I know that their use is controversial in
general so I would prefer to ask instead of just submitting the patch
using them a bunch sudden
compiler error: tree check: expected
record_type or union_type or qual_union_type, have integer_type in
finish_non_static_data_member, at cp/semantics.cc:2294
31 | auto f1 = [x](this auto&& self) {};
| ^
0x1c66dda tree_check_failed(tree_node const*, char co
On Sunday, November 19th, 2023 at 9:31 AM, Jason Merrill
wrote:
>
>
> On 11/19/23 08:39, waffl3x wrote:
>
> > Funny enough I ended up removing the ones I was thinking about, seems
> > to always happen when I ask style questions but I'm glad to hear it's
&
On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill
wrote:
>
>
> On 11/19/23 13:36, waffl3x wrote:
>
> > I'm having trouble fixing the error for this case, the control flow
> > when the functions are overloaded is much more complex.
> >
On Monday, November 20th, 2023 at 7:35 AM, Jason Merrill
wrote:
>
>
> On 11/19/23 16:44, waffl3x wrote:
>
> > On Sunday, November 19th, 2023 at 1:34 PM, Jason Merrill ja...@redhat.com
> > wrote:
> >
> > > On 11/19/23 13:36, waffl3x wrote:
>
> > > > /* Nonzero for FUNCTION_DECL means that this decl is a non-static
> > > > - member function. */
> > > > + member function, use DECL_IOBJ_MEMBER_FUNC_P instead. */
> > > > #define DECL_NONSTATIC_MEMBER_FUNCTION_P(NODE) \
> > > > (TREE_CODE (TREE_TYPE (NODE)) == METHOD_TYPE)
> > > >
> > > >
On Tuesday, November 21st, 2023 at 8:22 PM, Jason Merrill
wrote:
>
>
> On 11/21/23 08:04, waffl3x wrote:
>
> > Bootstrapped and tested on x86_64-linux with no regressions.
> >
> > Hopefully this patch is legible enough for reviewing purposes, I've not
On Wednesday, November 22nd, 2023 at 2:38 PM, Jason Merrill
wrote:
>
>
> On 11/22/23 15:46, waffl3x wrote:
>
> > On Tuesday, November 21st, 2023 at 8:22 PM, Jason Merrill ja...@redhat.com
> > wrote:
> >
> > > On 11/21/23 08:04, waffl
> and this in tsubst_lambda_expr that assumes iobj:
>
> /* Fix the type of 'this'. */
> fntype = build_memfn_type (fntype, type,
> type_memfn_quals (fntype),
> type_memfn_rqual (fntype));
Unfortunately, putting a condition on this had some unforeseen
consequences. I've been working on this about
perly
when the function_decl is substituted into. I don't really know where
the right place to do that is though, or really why it's not happening
already, so I'm just gonna poke around, try some things, and clean it
up later if it's messy.
That's my quick update, ho
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too. This is still a nasty hack so it should probably be done
differently, but I question if making a whole new fntype node in
tsubst_lambda_expr makes
excuse to leave a hole in the
compiler so, it's still gotta get done. I don't think I will get
rejection of mutation of captures done, especially since I'm uncertain
of what the right way to do it is, but maybe I'll work fast.
On Saturday, November 25th, 2023 at 10:32 AM, Jas
On Sunday, November 26th, 2023 at 2:30 PM, Jason Merrill
wrote:
>
>
> On 11/24/23 20:14, waffl3x wrote:
>
> > OKAY, I figured out SOMETHING, I think this should be fine. As noted in
> > the comments, this might be a better way of handling the static lambda
>
> > Now with that out of the way, I do still kind of feel icky about it.
> > This really is a MASSIVE edge case that will almost never matter. As
> > far as I know, instantiating explicitly like so...
> >
> > auto f = [x = 42](this auto&&) -> int { return x; };
> > int (*fp)(int&) = &decltype(f)::
> > > > OKAY, I figured out SOMETHING, I think this should be fine. As noted in
> > > > the comments, this might be a better way of handling the static lambda
> > > > case too. This is still a nasty hack so it should probably be done
> > > > differently, but I question if making a whole new fntype
On Sunday, November 26th, 2023 at 7:40 PM, Jason Merrill
wrote:
>
>
> On 11/26/23 20:44, waffl3x wrote:
>
> > > > > > The other problem I'm having is
> > > > > >
> > > > > > auto f0 = [n = 5, &m](this auto const&
This fixes the const bug. I haven't bootstrapped and tested beyond my
own tests yet but this does it. I don't know if this is the right way
to fix this yet, but I think it's pretty close. I'll see if I can make
a better write up tomorrow, but it seems to me that since we never
cared about substitut
On Wednesday, November 29th, 2023 at 10:00 PM, Jason Merrill
wrote:
>
>
> On 11/27/23 00:35, waffl3x wrote:
>
> > I think this is cleaned up enough to be presentable. Bootstrapped but
> > not tested but I don't think I changed anything substantial. I am
&g
> Thank you, this is great!
Thanks!
> One legal hurdle to start with: our DCO policy
> (https://gcc.gnu.org/dco.html) requires real names in the sign-off, not
> pseudonyms. If you would prefer to contribute under this pseudonym, I
> encourage you to file a copyright assignment with the FSF, who a
> This seems like a reasonable place for it since 'this' is supposed to
> precede the decl-specifiers, and since we are parsing initial attributes
> here rather than in the caller. You will want to give an error if
> found_decl_spec is set. And elsewhere complain about 'this' on
> parameters after
ident that it's my preferred option going forward
though. Hopefully they get back to me soon.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
From bbfbcc72e8c0868559284352c71731394c98441e Mon Sep 17 00:00:00 2001
From: waffl3x
Date: Mon, 25 Sep 2023 16:59:10 -0600
Subject: [PATCH] c++:
023-09-27 04:43 p.m., Hans-Peter Nilsson wrote:
>> Date: Tue, 26 Sep 2023 01:56:55 +
>> From: waffl3x
>
>> Signed-off-by: waffl3x
>
> I think I've read that you have to put your actual name in
> the DCO; using an alias (presumably) as above would be
>
From 0403104f65dd8cce4c71270d492d0922a7f2702c Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Tue, 8 Jul 2025 19:28:12 -0600
Subject: [PATCH 2/3] tree: Add 7 and 8 argument TREE_CHECK_* and
TREE_NOT_CHECK_*
I needed an 8 argument version of TREE_NOT_CHECK_*, it felt wrong to leave
a gap so the
From 11f2b46bb882c427f45f194196d89b22ec470240 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Tue, 8 Jul 2025 19:52:05 -0600
Subject: [PATCH 3/3] middle-end/121005 Add checks for TREE_LANG_FLAG_*
TREE_LANG_FLAG_* is only valid for tree codes that do not use other union
fields in tree_base
From d7107c64189f944adfb64f9e8acfb7ed2cbfe796 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Tue, 8 Jul 2025 19:25:20 -0600
Subject: [PATCH 1/3] tree: Add TREE_NOT_RANGE_CHECK
There was no inverted counterpart to TREE_RANGE_CHECK, this adds one.
gcc/ChangeLog:
* tree.cc
This set of patches are not tested quite yet, I'm going to start it as
soon as I finish this e-mail.
I would really like to implement the multiple argument tree_check* and
tree_not_check* as a variadic template. I know how to do it in such a
way that would limit the amount of instantiations, and
From 979825e4528bebf5ed83b5580e3d39fb738f43b7 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Tue, 8 Jul 2025 19:28:12 -0600
Subject: [PATCH 2/3] tree: Add 7 and 8 argument TREE_[NOT_]CHECK_*
I needed an 8 argument version of TREE_NOT_CHECK_*, it felt wrong to leave
a gap so the other versions are
Fixed some very obvious errors that should have been fixed before I
submitted v1, lesson learned this time I hope.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
From 32fa771d65eeca675d268bcf96b654fe5ac64eaf Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Tue, 8 Jul 2025 19:25:20
From df25e9a27938123e4e3737f1532b402b0fd320e3 Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Tue, 8 Jul 2025 19:52:05 -0600
Subject: [PATCH 3/3] middle-end/121005 Add checks for TREE_LANG_FLAG_*
TREE_LANG_FLAG_* is only valid for tree codes that do not use other union
fields in tree_base
ny circumstances where TREE_CODE is FUNCTION_DECL but the
lang_specific member is null? I have a null check for that case in
DECL_IS_XOBJ_MEMBER_FUNC
but I question if it's necessary.
From e485a79ec5656e72ba46053618843c3d69331eab Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Thu, 31 Aug 2023 01:05:25
n up otherwise.
From d82a34432364b391abde44a23ceacb3c398a519d Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Thu, 31 Aug 2023 02:13:52 -0400
Subject: [PATCH 2/2] P0847R7 (deducing this) Extended diagnostics
gcc/cp/ChangeLog:
* cp-tree.h (TFF_XOBJ_FUNC): new flag to identify that an explicit object member function's par
Hey Jakub, thanks for the response
and criticism, as soon as I am
back at a computer I will address
the issues you raised, I have a few
questions though.
I apologize in advanced for any
errors in formatting this message,
I'm writing it from a hotel room
on a phone so errors are inevitable,
but I'l
00:00:00 2001
From: Waffl3x
Date: Mon, 11 Sep 2023 04:21:10 -0600
Subject: [PATCH] c++: Initial support for C++23 P0847R7 (Deducing This)
[PR102609]
This patch implements initial support for P0847R7, without additions to
diagnostics. Almost everything should work correctly, barring a few
81 matches
Mail list logo
