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
