[Bug c++/13590] [3.3/3.4/3.5 regression] Non-existing ambiguity when inhering through virtuals two identical using declarations.

["nathan at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From nathan at gcc dot gnu dot org  2004-03-05 14:44 -------
I am not conviced this code is valid. [10.2] describes member name lookup
in an MI lattice, and says that 'each declaration that was introduced by a
using-declaration is considered to be from each subobject of C that is of the
type containg the declaration descignated by the using declaration'. ... 'if the
resulting set of declarations are not all from sbobjects of the same type ...
there is an ambiguity'.  Whilst those rules make sense for data members, they do
not for function members.  The set of overloaded functions can include some from
a base, brought in by a using declaration, and some declared in the class
containing the using declaration [7.3.3]/12   If those from the base were
considered to actually be from the base, then we'd have a set from differnt
types, so be ambiguous.

Thus, I think we have to consider overloaded functions to be from the class
containing the using declaration (and not the class being used).  If that is the
case, then the code is ill-formed, even though both using declarations refer to
the same unambiguous base object.

The original testcase had added an overload on one path through the graph, if we
augment the case with an additional overload on the other path, it quite clearly
must be ambiguous (because it would be without the using declarations).

Wolfgang's reduced test case, with just using declarations it the other
interesting example.  If we treat this as ambiguous, then it appears that (in
other useages), we could use using declarations to resolve inherited member
ambiguities -- something expressly forbidden by [10.2] (footnote 96).  So this
argues that the reduced case should be well formed.

But, now we have some strangeness.  Whether a function using declaration's
naming class is the class of the using declaration of the class of the used
declaration depends on whether there are any additional overloads.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590