https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114632
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113388
--- Comment #1 from waffl3x ---
Yeah, looks like a bug. I won't be able to look at it as I am in the
process of moving but it seems like a similar one to PR113348.
Thanks for the report!
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
struct S
{
void f(this S& self) {}
void g(this S self) { f(); }
};
void test()
{
S{}.g();
}
Som
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: [PATCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #29 from waffl3x ---
https://cplusplus.github.io/CWG/issues/2789.html
My alteration to CWG2789 came up on reddit and I realized I should
probably post about it here.
Instead of:
"if both are non-static member functions, they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #26 from waffl3x ---
(In reply to corentinjabot from comment #25)
> Hey folks.
> Congrats on landing support for deducing this in GCC.
Thanks!
> While there is no spec for it, after discussion here,
> https://github
On Wednesday, January 10th, 2024 at 7:34 PM, Jason Merrill via Gcc
wrote:
>
>
> On 1/10/24 16:41, Marek Polacek wrote:
>
> > On Wed, Jan 10, 2024 at 04:24:42PM -0500, Jason Merrill wrote:
> >
> > > On 1/10/24 15:59, Marek Polacek wrote:
> > >
> > > > On Wed, Jan 10, 2024 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113307
--- Comment #1 from waffl3x ---
I'm on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308
--- Comment #3 from waffl3x ---
I meant to post this link instead of one of the others.
https://godbolt.org/z/oMP8185Yh
I guess I shouldn't be replying to things while still waking up, sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308
--- Comment #2 from waffl3x ---
(In reply to Nathaniel Shead from comment #1)
> I believe this is correct behaviour: The definition of `operator++` in the
> child class hides the `operator++` declared in the base class. Sim
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
> > incl
On Sunday, January 7th, 2024 at 3:22 PM, Jakub Jelinek wrote:
>
>
> On Sun, Jan 07, 2024 at 03:12:32PM -0700, Jeff Law via Gcc wrote:
>
> > On 1/7/24 08:48, waffl3x via Gcc wrote:
> >
> > > https://gcc.gnu.org/develop.html#timeline
> > >
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
https://gcc.gnu.org/develop.html#timeline
The date for stage 4 is listed as the 8th on here, is that date final?
There is at least 1 patch pending (mine) that is complete but Jason
Merril hasn't been active for a few days. He had expressed to me that
he expected the date to be next week on the
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 i
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
, 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 to lang_decl_fn and a corresponding
ll 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, I ended up doing a bit mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
--- Comment #2 from waffl3x ---
> Looking at the above commit, joust already takes care to check
> more_constrained for non-template functions, and only if their function
> parameters match according to cand_parms_match.
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.
Alex
On Monday, January 1st, 2024 at 8:34 AM, waffl3x wrote
declared in the derived class
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail
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 been at this for a while, and I'm not
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/23 04:01, waffl3x wrote:
> > >
> > > > int n = 0;
> > >
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
I am including all 3 bugs in a single report as they are similar and
located in the same region of code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83417
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #5
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
> > expl
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 the
&g
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 tes
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
template inline constexpr bool not_int_v = !__is_same (T, int);
template concept NotInt = not_int_v
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
as both new and
having disappeared. This is because some of the tests either
incorrectly include the full patch, or include the line number. Here's
examples of each of these from my latest comparison.
```
New tests that FAIL (4 tests):
g++.dg/modules/xtreme-header-4_b.C -std=c++2b (internal compiler error:
>> @@ -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
> &
a mismatched deduced return type
Product: gcc
Version: 4.9.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
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
>
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
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, ](this auto const&){ n = 1
> > > > 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&) =
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
>
ovember 25th, 2023 at 10:32 AM, Jason Merrill
wrote:
>
>
> On 11/24/23 01:49, waffl3x wrote:
>
> > > and this in tsubst_lambda_expr that assumes iobj:
> > >
> > > /* Fix the type of 'this'. */
> > > fntype = build_memfn_type (fntype, type,
>
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
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, hopefully this gets me somewhere finally.
Alex
On Thursday, November 23rd, 2023 at 11:49 PM, waffl3x
> 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, w
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
&g
> > > > /* 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.
> >
&g
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
> > o
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 const*, int, char const*,
...)
/h
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
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
> [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 signif
> > 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,
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 threw t
> > 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)));
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)
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 2023 05:17:18 -0700
Subject: [PATCH 2/2] c
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 support for P0847R7 without diagnostics. My goal
was to minimize changes to the existing code
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 \
> > 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
, 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 week and I'll
> try
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
MEM_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", t); return error_mark_node; } /* -- Waffl3x additions start --
> */ /* Exception for non-overlo
(TREE_TYPE (t)))
{
if (complain & tf_error)
error_at (loc,
"cannot create pointer to reference member %qD", t);
return error_mark_node;
}
/* -- Waffl3x additions start -- */
/* Exceptio
> >
> > 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 ove
> 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
> ::f syntax, so we could build a pointer to
> 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
> (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
> >
> 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
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
> wrong.
>
> A
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++: Initial support for C++23 P0847R7 (Deducing This)
[PR
> 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #18 from waffl3x ---
(In reply to Gašper Ažman from comment #17)
> Read through the patch quickly, want to suggest a few tests.
>
> When a lambda has captures, the explicit object parameter is used to get at
> th
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #16 from waffl3x ---
Just gotta note that the patch posted here had an oversight, it never worked as
I hoped. The good news is, I submitted a finalized patch to the patch maillist,
just before I have to leave. Thanks for the help
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 parameters are being printed
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 -0400
Subject: [PATCH] P0847R7 (deducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #15 from waffl3x ---
Created attachment 55793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55793=edit
inital support for P0847 explicit-object-parameter
Alright, I finalized something that I hope is worthy of criticism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #13 from waffl3x ---
I am finding myself realizing that implementing this as a member function and
turning off member function bits seems to be more difficult than implementing
it as a static function and implementing member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #11 from waffl3x ---
(In reply to Jonathan Wakely from comment #9)
> If we're right about that, then I agree that a warning would be useful for
> classes that have no such implicit conversion from S to S*.
>
> I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #7 from waffl3x ---
struct S {
int f(this S*) {
return 5;
}
};
int main()
{
S s{};
return s.f();
}
Here is my current progress, this code works. I have a good feeling that the
rest is going to be easy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #6 from waffl3x ---
I've noticed the standard does call `this` a specifier, I will perhaps rework
the code to just do parsing in cp_decl_specifier_seq.
(In reply to Gašper Ažman from comment #5)
> And of course by "this&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #3 from waffl3x ---
I have some elements working so far, I opted to implement parsing for `this` in
cp_parser_parameter_declaration instead of in cp_parser_decl_specifier_seq
because I didn't want to add another member
1 - 100 of 122 matches
Mail list logo
