Name mangling for explicit overriders

[J. Stephen Adamczyk]

We recently implemented the Microsoft extension that allows explicit
specification of overriding on derived class virtual functions.
For example:

	struct B1 {
	  virtual void f() = 0;
	};
	struct B2 {
	  virtual void f() = 0;
	};
	struct D: B1, B2 {
	  virtual void B1::f() {}  // Overrides B1::f (only)
	  virtual void B2::f() {}  // Overrides B2::f (only)
	};

(Hey, we didn't invent it; we're just implementing it for Microsoft
compatibility. :-) )

This has a name mangling implication: as shown in the above example,
you can end up with two member functions in a given class that have
the same name and signature, and differ only in the function that
they override.

Here's the extension we made to name mangling, so that others who
have to do this feature might do it the same way, or so that anyone
who sees a problem with what we did can warn us now before we ship
it.

We added a rule for <encoding>:

  <encoding> ::= <function name> O <nested-name> <bare-function-type>

The <nested-name> in this case names the overridden function.  So,
for example, the B1::f overrider in D is encoded as

  _ZN1D1fEON2B11fEv
	  ^^^^^^^^------ this is the O <nested-name> part

We demangle this as

  D::f [overriding B1::f] ()

We considered putting the added information inside the existing
<function name>, but it seemed more like an added bit of information
about the function than a part of the function name.  I also felt
that the mangling and demangling of a <nested-name> is already
complicated, especially with regard to prefixes and substitutions,
and I wanted to avoid complicating it further.

We also considered naming only the overridden class, not the
function, but decided that other explicit-override extensions
might allow overriding of differently-named functions, and
therefore generality should be chosen over brevity.

Any comments?

Steve Adamczyk
Edison Design Group