[PATCH] D12686: Add support for GCC's '__auto_type' extension.

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 12 12:06:02 PDT 2015


rsmith added inline comments.

================
Comment at: include/clang/Basic/DiagnosticSemaKinds.td:1726
@@ -1720,1 +1725,3 @@
+def err_auto_bitfield : Error<
+  "cannot pass bit-field as __auto_type initializer in C">;
 
----------------
pass -> use

Also, why not? Just because GCC messes this up, doesn't mean we have to.

================
Comment at: lib/AST/ItaniumMangle.cpp:2557-2558
@@ -2557,1 +2556,4 @@
+  if (D.isNull()) {
+    assert(T->getKeyword() != AutoTypeKeyword::GNUAutoType &&
+           "shouldn't need to mangle __auto_type!");
     Out << (T->isDecltypeAuto() ? "Dc" : "Da");
----------------
Why not?

  template<typename T> void f(decltype(new __auto_type(T())));

... would need a mangling, right? (Or do you prohibit `__auto_type` there?)

================
Comment at: lib/Parse/ParseDeclCXX.cpp:1119
@@ -1118,2 +1118,3 @@
   case tok::kw_auto:            // struct foo {...} auto      x;
+  case tok::kw___auto_type:     // struct foo {...} __auto_type x;
   case tok::kw_mutable:         // struct foo {...} mutable   x;
----------------
That would be ill-formed; revert this change.

================
Comment at: lib/Sema/SemaExpr.cpp:352
@@ -351,1 +351,3 @@
   if (ParsingInitForAutoVars.count(D)) {
+    const AutoType* AT = cast<VarDecl>(D)->getType()->getContainedAutoType();
+
----------------
This has not been addressed.

================
Comment at: lib/Sema/SemaType.cpp:1457
@@ -1455,3 +1456,3 @@
     // being analyzed (which tracks the invented type template parameter).
     if (declarator.getContext() == Declarator::LambdaExprParameterContext) {
       sema::LambdaScopeInfo *LSI = S.getCurLambda();
----------------
Should we really allow using `__auto_type` to introduce a generic lambda? It seems like there's a major open design question here: either we should allow `__auto_type` only in GCC-compatible contexts (that is, as a decl-specifier that's not a function return type), or we should allow it everywhere we allow `auto` and make it a synonym for `auto` in C++ (in which case it needs to be mangled, and the distinction between `auto` and `__auto_type` should probably not affect the canonical type).

================
Comment at: lib/Sema/SemaType.cpp:2654-2655
@@ -2648,4 +2653,4 @@
     case Declarator::ConversionIdContext:
       if (!SemaRef.getLangOpts().CPlusPlus14)
-        Error = 12; // conversion-type-id
+        Error = 14; // conversion-type-id
       break;
----------------
Do you really want to allow `__auto_type` here? This is inconsistent with what you do for return types.


http://reviews.llvm.org/D12686





More information about the cfe-commits mailing list