Hi, 2011/10/12 Jason Merrill <ja...@redhat.com>: >>> Copying the decl is unlikely to do what we want, I think. Does putting >>> the >>> target decl directly into the method vec work? >> >> Unfortunately not, it ends up with the same error: undefined >> reference. > > Hunh, that's surprising. > >> Furthermore, I don't think it is the right approach since >> the access may be different between the member function and the using >> declaration... Never mind. > > I would expect the existing access declaration code to deal with that, > though I could be wrong.
After looking into it a bit more, I now see things differently. The target_decl is in fact put into the CLASSTYPE_METHOD_VEC at instantiation time, via handle_using_decl, with the correct access. The problem is that while parsing the template (before instantiating), it is not yet there and an error is immediately raised. I only see three solutions: 1) perform an additional lookup for using declarations that designate functions in lookup_fnfields_slot to find something even if the CLASSTYPE_METOD_VEC is empty (what I implemented in the previous patch) 2) inhibate the lookup error at some point. 3) put the decl into the CLASSTYPE_METHOD_VEC before instantiation Honnestly, I don't know if 2) is realistic, and how to implement it as well ... 3) seems complicated: in finish_member_declaration, we must put away the decl into TYPE_FIELDS or TYPE_METHODS, but we would like to put the target_decl into TYPE_METHODS (and call add_method), and at the same time put its using decl into TYPE_FIELDS... I don't know if it can theoretically work, but having try it, I think it would need many adjustements. What do you make of it ? > There don't seem to be any tests for a class that both uses and defines > functions with the same name to verify that both functions can be called; I > suspect that doesn't work yet with this patch. If we can't put the used > functions directly into CLASSTYPE_METHOD_VEC, we need to combine them with > functions from there at lookup time. Since the using decl is actually put into the CLASSTYPE_METHOD_VEC at instantiation time, I think we don't have to worry about it. >> + if (TREE_CODE (target_field) == FUNCTION_DECL >> + && DECL_NAME (OVL_CURRENT (target_field)) == name) > > Checking for FUNCTION_DECL won't work if the target is overloaded. Will be fixed. [...] >>Does the attached testcase checked what you mention ? >Yes, that's what I had in mind. This testcase passes. -- Fabien
