[PATCH] PR13236 - Microsoft compatibility: support __super specifier to access members of base classes

Reid Kleckner rnk at google.com
Mon Jul 14 16:27:17 PDT 2014


On Sun, Jul 13, 2014 at 6:43 PM, Nikola Smiljanić <popizdeh at gmail.com>
wrote:

> Thanks for the input guys, I have two questions:
>
> 1. MSDN states "__super can only appear within the body of a member
> function." and yet msvc accepts it in a number of places (data member
> declaration, typedef, etc.). Do we wan't to be bug for bug compatible with
> msvc as I see that as major pain?
>

I'm OK with accepting it anywhere inside a class.  I think their
documentation is trying to warn the user that it won't work if you use it
in a class template.  Consider this behavior:

template <typename T> struct A : T { __super::InnerType m; };

t.cpp(1) : error C2791: illegal use of 'super': 'A<T>' does not have any
base classes
        t.cpp(1) : see reference to class template instantiation 'A<T>'
being compiled

My guess is that MSVC tries to do token substitution on __super as early as
possible.  This breaks down when you have dependent base classes, because
you can't look the name up inside the template parameter.

2. I agree with Aaron that we should support the 'name found in multiple
> bases' scenario. In theory this is simple enough, but I don't know how hard
> it is to implement in practice. I guess this is a question for Richard, can
> I get ambiguous declarations from LookupResult (I see that this is
> possible) and do an overload resolution on them (this looks more difficult
> as I don't know how to access the call arguments)?


I think we need to do some overload resolution.  MSVC resolves __super to B
in this case:
struct A { void foo(int); };
struct B { void foo(short); };
struct C : A, B {
  void foo(short x) {
    __super::foo(x);
  }
};

And they error out if you s/short/int/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140714/5e269e42/attachment.html>


More information about the cfe-commits mailing list