> 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
Ah okay I think that sheds a little bit of light on things, and here I was trying not to involve overloads to make it easier for me to understand things, it seems it ended up making me miss some things. At a glance it seems like all I need to do then is disable the PTRMEM_OK_P flag then. I will try that and see how it goes, provided I can find where it's all setup. (I think I'm almost to the bottom of it, but it's tough to unravel so I'm not sure.) I'm also now realizing it's probably about time I add more tests involving overloads, because I avoided that early on and I don't think I ever got around to adding any for that. Alex
