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: [
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
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&
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
> >
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 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.
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
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
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
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,
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
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
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/
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}
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 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
> >
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 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
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
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
>> @@ -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);
>> +
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
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 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
> &
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 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
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 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&
> > > > 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
> > 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)::
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
>
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
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
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
> 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
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
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
> > > > /* 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 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:
>
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 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
&
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
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
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:
> > >
> > > > > &
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
> [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
> > 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
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'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 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 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) !=
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
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
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
> > 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
--
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
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
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
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
> >
> > 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 {
> (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
> 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
> 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
> (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,
> > 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
> 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
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
>
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++:
> 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
> 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
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
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
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
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
74 matches
Mail list logo
