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:
> > >
> > > > I'm having trouble fixing the
On 11/19/23 16:44, 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.
struct S {
void f(this
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.
> >
> > struct S {
> > void f(this S&) {}
> >
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.
struct S {
void f(this S&) {}
void f(this S&, int)
void g() {
void (*fp)(S&) =
}
};
This seemed to have fixed the non
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
> > okay going forward.
> >
> > I'm
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
okay going forward.
I'm having trouble fixing this bug, based on what Gasper said in
PR102609 I am pretty sure I know
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
okay going forward.
I'm having trouble fixing this bug, based on what Gasper said in
PR102609 I am pretty sure I know what the semantics should be. Since
the
On Sat, Nov 18, 2023 at 1:43 AM 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
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:
> > >
> > > > > > There are a few known issues still present in this patch. Most
> > > > > >
On 11/11/23 05:43, waffl3x wrote:
[combined reply to all three threads]
On 11/9/23 23:24, waffl3x wrote:
There are a few known issues still present in this patch. Most importantly,
the implicit object argument fails to convert when passed to by-value xobj
parameters. This occurs both for xobj
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 significant bit to
> > > > indicate whether a function is virtual,
[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 significant bit to indicate
whether a function is virtual, ensure a pointer to this function will have
> > 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
On 11/4/23 02:40, waffl3x wrote:
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
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 \
On 11/3/23 00:44, waffl3x wrote:
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
> > 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
On 10/28/23 00:07, waffl3x wrote:
I wanted to change DECL_NONSTATIC_MEMBER_FUNCTION_P to include explicit
object member functions, but it had some problems when I made the
modification. I also noticed that it's used in cp-objcp-common.cc so
would making changes to it be a bad idea?
-- cp-tree.h
On Wed, Nov 01, 2023 at 11:15:56PM +, waffl3x wrote:
> Just want to quickly check, when is the cutoff for GCC14 exactly? I
Nov 18th EOD. But generally it is cutoff for posting new feature patches
that could be accepted, patches posted before the deadline if reviewed
soon after the deadline
The problem with operators is fixed, now starts a long period of
testing. It's been so long since I've gotten to this part that I almost
forgot that I have to do it :'). When/if regtests and bootstrap all
pass I will format the patch and submit it.
--- Original Message ---
On Wednesday,
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
I woke up today and figured it out in about 30 minutes, I don't know if
this solution would be okay but I am running away from
cp_build_addr_expr_1 for now. I think this is another place I will have
the urge to refactor in the future, but if I keep looking at it right
now I am just going to waste
I've been under the weather so I took a few days break, I honestly was
also very reluctant to pick it back up. The current problem is what I
like to call "not friendly", but I am back at it now.
> > I don't understand what this means exactly, under what circumstances
> > would find the member
On 10/20/23 00:34, waffl3x wrote:
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,
> >
> > 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
On 10/19/23 19:35, waffl3x wrote:
(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
> (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 overload set. That is, if
> 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
On 10/19/23 17:05, waffl3x wrote:
Also, I'm not sure what %qs is, should I be using that instead of %s
for strings?
The q prefix means quoted, with ' or other quotation marks, depending on
the locale.
On another topic, I have been trying to fix taking pointers to explicit
object member
On Thu, Oct 19, 2023 at 09:31:06PM +, waffl3x wrote:
> Ah alright, I see what you're saying, I see what the difference is now.
> It's a shame we can't have the translated string insert a %s and format
> into that :^). Ah well, I guess this code is just doomed to look poor
> then, what can you
> 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
On Thu, Oct 19, 2023 at 09:05:38PM +, waffl3x wrote:
> Okay so taking what you guys are saying here it sounds like it would be
> appropriate to refactor the code I was reluctant to refactor. The code
> (in grokfndecl) conditionally selects one of the two (now three with my
> changes) following
> (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,
On 10/18/23 13:28, waffl3x wrote:
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
On Wed, Oct 18, 2023 at 05:28:10PM +, waffl3x wrote:
> I've seen plenty of these G_ or _ macros on strings around like in
> grokfndecl for these errors.
>
> G_("static member function %qD cannot have cv-qualifier")
> G_("non-member function %qD cannot have cv-qualifier")
>
> G_("static
> > 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
> >
On 10/18/23 07:46, waffl3x wrote:
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
> 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
On 9/25/23 21:56, waffl3x wrote:
On the plus side, I took my time to figure out how to best to pass down
information about whether a param is an xobj param. My initial
impression on what you were suggesting was to push another node on the
front of the list, but I stared at it for a few hours
On 9/25/23 21:56, waffl3x wrote:
Also, just a quick update on my copyright assignment, I have sent an
e-mail to the FSF and haven't gotten a response yet. From what I was
reading, I am confident that it's my preferred option going forward
though. Hopefully they get back to me soon.
Any
Not to worry, I'm currently going through that process with the FSF, it
was confirmed that a pseudonym should be just fine. I don't know how
long the process takes but my goal is to get this in for GCC14, and
surely this won't take more than a month. One can only hope anyway.
On 2023-09-27 04:43
> 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.
Ah, it's on https://gcc.gnu.org/dco.html - the *second* DCO
link; under "Signed-off-by", on
> Yes, but I'll warn you that grokdeclarator has resisted refactoring for
> a long time...
That will certainly be what I work on after this is squared off then,
I've been up and down grokdeclarator so I'm confident I'll be able to
do it.
As for the patch, I sure took my sweet time with it, but
45 matches
Mail list logo
