https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #31 from waffl3x ---
(In reply to Gašper Ažman from comment #30)
> I don't really understand what you meant by "they have corresponding object
> parameters" - you mean that the object parameters are equal in both
> constraint and typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #30 from Gašper Ažman ---
I don't really understand what you meant by "they have corresponding object
parameters" - you mean that the object parameters are equal in both constraint
and type? "Corresponding" to my recollection is only
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 have th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #28 from Jakub Jelinek ---
It doesn't help that the mangling issue doesn't have implementation in form of
a mangling ABI patch, that would help to figure out e.g. whether it either H or
CV-qualifiers ref-qualifiers.
Anyway, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #27 from Gašper Ažman ---
I think there is an example in the standard that distinguishes those two as
far as overload resolution is concerned.
On Thu, Jan 11, 2024, 21:08 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wro
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.com/itanium-cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #23 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:07d09f0af100a9873982fba663800d87bfd73585
commit r14-7077-g07d09f0af100a9873982fba663800d87bfd73585
Author: waffl3x
Date: Sun Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #24 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:bfad006b88ec26e91b7edf9cf9ad4aaf9b8a9727
commit r14-7078-gbfad006b88ec26e91b7edf9cf9ad4aaf9b8a9727
Author: waffl3x
Date: Sun Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #22 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:f8bf6a69e260a5f1aa0dbf89a6e4bcdf1a24af5d
commit r14-7076-gf8bf6a69e260a5f1aa0dbf89a6e4bcdf1a24af5d
Author: waffl3x
Date: Sun Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #20 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:f9fbf93dc82525a0f54a2293b7ec92d65776bf19
commit r14-7074-gf9fbf93dc82525a0f54a2293b7ec92d65776bf19
Author: waffl3x
Date: Sun Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #21 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:fbc980d85149409ce62c22f48d3693113803929e
commit r14-7075-gfbc980d85149409ce62c22f48d3693113803929e
Author: waffl3x
Date: Sun Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #19 from Gašper Ažman ---
Correct, the use of the capture is the source of the error, not the
instantiation with an unrelated type.
On Sat, Sep 2, 2023, 09:54 waffl3x at protonmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:
> https
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
> them *silently*, if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #17 from Gašper Ažman ---
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
them *silently*, if they are related, otherwise the program is ill-fo
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 eve
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&action=edit
inital support for P0847 explicit-object-parameter
Alright, I finalized something that I hope is worthy of criticis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #14 from Barry Revzin ---
> 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 me
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 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #12 from Gašper Ažman ---
Replies to relevant snippets inline.
That was quite a write-up!
> The only compelling case I can think of for such a thing would be passing a
> pointer type that isn't related by inheritance anyway. That
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 the warning wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #10 from Gašper Ažman ---
Yes, the explicit object parameter always receives the cv-l/r qualified
reference to the object of the call. Implicit conversions are then of
course allowed, same as any other parameter. S* is not that usefu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #9 from Jonathan Wakely ---
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 the warning would give a false positive in the case below, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #8 from Jonathan Wakely ---
I don't see anything forbidding that declaration, but I think it can only be
called if S& has an implicit conversion to S* because the object parameter is
an lvalue of type S, and so it can only match S* v
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. Excep
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" I meant sup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #5 from Gašper Ažman ---
And of course by "this" I meant support for a default argument on the explicit
object parameter.
We might add it back in the future if we find a usecase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #4 from Gašper Ažman ---
As one of the authors, I can assure you you never need to implement this for
c++23.
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 to cp_decl_spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #2 from Marek Polacek ---
Related: https://cplusplus.github.io/CWG/issues/2653.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
31 matches
Mail list logo
