On 1/9/24 17:34, waffl3x wrote:
On Tuesday, January 9th, 2024 at 2:56 PM, Jason Merrill <ja...@redhat.com>
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'm considering this finished, I have CWG2586 working but I have not
included it in this version of the patch. I was not happy with the
amount of work I had done on it. I will try to get it finished before
we get cut off, and I'm pretty sure I can. I just don't want to risk
missing the boat for the whole patch just for that.
There aren't too many changes from v7, it's mostly just cleaned up.
There are a few though, so do take a look, if there's anything severe I
can rush to fix it if necessary.
That's all, hopefully all is good, fingers crossed.
Great. Given where we are in the release cycle, I'm thinking to put
these with only minimal changes and then do any further adjustments
afterward.
For this first one, I needed to fix the commit message to wrap at 75
columns so that it fits in 80 columns with the initial padding added by
'git log'. I also needed to adjust the ChangeLog entry to please git
gcc-verify. And I changed the credit note to a Co-authored-by.
The other commit messages only needed wrapping.
I just pushed your patches along with these two follow-ons:
Is the type of an implicit object parameter specified elsewhere? I have
looked for it more than once and I could only find that passage, but I
guess [over.match.funcs-1] is what I missed here, so
[over.match.funcs-4] doesn't apply elsewhere.
That's the only definition I know of. And indeed my statement was
wrong, it also affects the considerations in add_method. But I still
think it would be more complicated in more places to deal with proxy
FUNCTION_DECLs (like we do for inheriting constructors).
I have no objection to changing the comment in
iobj_xobj_parameters_correspond if you have a better idea on how to fix
the bug that inspired that comment. Especially since the standard is on
your side for it.
In this case, perhaps the comment should instead say something along
the lines of "this function does not account for using declarations."
That does get a little hairy though if both an iobj and xobj member
function are introduced by a using declaration. Perhaps we should just
optionally take a type that we can compare against? That sounds really
icky, maybe the solution you have in mind will work just fine.
BTW, I definitely assumed TYPE_MAIN_VARIANT was what I wanted in other
places in the patch, so there might be latent errors waiting to happen.
It's probably fine because those areas where I used them are pretty
well tested, but I thought it would be worth mentioning just in case.
The uses in copy_fn_p seem a little dubious, but there were already
similar ones there, so I think it should be OK.
I'm very excited to see this get through, thanks again for all the help
and patience.
Thank you for all your work!
Jason
