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

Reid Kleckner rnk at google.com
Fri Jul 11 14:47:30 PDT 2014


================
Comment at: lib/AST/ItaniumMangle.cpp:804-806
@@ -803,2 +803,5 @@
   switch (qualifier->getKind()) {
+  case NestedNameSpecifier::MsSuper:
+    // nothing
+    return;
   case NestedNameSpecifier::Global:
----------------
This seems bad.  IMO we can mangle this as a source name of __super.  It's in the implementer's namespace, so we should be OK.  Please add a test for this.  I think if you instantiate a template with a non-type template parameter using __super you'll get this mangling.

================
Comment at: lib/AST/NestedNameSpecifier.cpp:190-191
@@ -172,3 +189,4 @@
   case Global:
+  case MsSuper:
     return false;
 
----------------
That seems wrong.  It's dependent if there are dependent bases.  Consider:

  template <typename T>
  struct A : T {
    __super::TypeFromBase x;
  };

Maybe a __super specifier should store the RecordType that it will search inside of so that we can ask it this kind of question?

================
Comment at: lib/Parse/ParseExprCXX.cpp:230
@@ +229,3 @@
+    if (Tok.isNot(tok::coloncolon)) {
+      // XXX: Diagnose
+      return true;
----------------
Please fix.

================
Comment at: lib/Sema/SemaCXXScopeSpec.cpp:153
@@ -151,1 +152,3 @@
+  case NestedNameSpecifier::MsSuper:
+    return nullptr;
   }
----------------
It might make more sense to treat this more like a TypeSpec NNS, and to return a stored tag decl here.

================
Comment at: lib/Sema/SemaExpr.cpp:1953-1955
@@ +1952,5 @@
+  if (LookupInBaseClasses(R, Rec)) {
+    // if (R.getAmbiguityKind() == LookupResult::AmbiguousBaseSubobjectTypes) {
+    // Do overload resolution?
+    // }
+
----------------
I'm not sure what should happen here...

================
Comment at: lib/Sema/TreeTransform.h:3067-3068
@@ -3066,1 +3066,4 @@
 
+  case NestedNameSpecifier::MsSuper:
+    // There is no meaningful transformation that one could perform on the
+    // __super specifier.
----------------
If we go the route of storing the tag decl of the class that __super was used in, we will end up wanting to transform that decl from a pattern to a specialization.

================
Comment at: test/SemaCXX/MicrosoftExtensions.cpp:444
@@ +443,2 @@
+  }
+}
----------------
Missing semicolon and closing brace for namespace?

This could also use a lot more tests.

http://reviews.llvm.org/D4468






More information about the cfe-commits mailing list