Re: [PATCH v3 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[Jason Merrill <jason@redhat.com>]

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 functions today, as I ended up breaking that when I
> started setting static_function to false for them. Originally it just
> worked so I haven't touched any code related to this, but now that they
> aren't being treating like static member functions as much so a few
> things just broke. What I'm asking myself now is whether it would be
> appropriate to just opt-in to static member function behavior for this
> one, and I'm not sure that would be correct.
> 
> So I started by checking what it did before I turned off the
> static_function flag. It's was being passed into cp_build_addr_expr_1
> as a baselink node, while regular member functions are passed in as an
> offset_ref node. I then checked what the case is for static member
> function, and unsurprisingly those are also handled wrapped in a
> baselink node, but this raised some questions for me.
> 
> I am now trying to figure out what exactly a baselink is, and why it's
> used for static member functions. My current best guess is that
> method_type nodes already hold the information that a baselink does,
> and that information is needed in general. If that is the case, it
> might just be correct to just do the same thing for explicit object
> member functions, but I wonder if there is more to it, but maybe there
> isn't. It worked just fine before when the static_function was still
> being set after all.
> 
> Any insight on this is appreciated.

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 member if it resolves to an 
implicit-object member function.

For an overload set containing only a single static member function, 
build_offset_ref doesn't bother to build an OFFSET_REF, but returns the 
BASELINK itself.

I think we need the OFFSET_REF for an explicit-object member function 
because it expresses that the code satisfies the requirement "If the 
operand names an explicit object member function, the operand shall be a 
qualified-id."

It might simplify things to remove the optimization in build_offset_ref 
so we get an OFFSET_REF even for a single static member function, and 
add support for that to cp_build_addr_expr_1.

Jason