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

[Nicholas Allegra via cfe-commits]

comex marked 5 inline comments as done.

================
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">;
 
----------------
rsmith wrote:
> pass -> use
> 
> Also, why not? Just because GCC messes this up, doesn't mean we have to.
By analogy with the standards-defined inability to use sizeof on bit fields, it made sense to me to do what GCC does and forbid getting their type in other ways.  Though I suppose the restriction is somewhat questionable in the first place.

================
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");
----------------
rsmith wrote:
> Why not?
> 
>   template<typename T> void f(decltype(new __auto_type(T())));
> 
> ... would need a mangling, right? (Or do you prohibit `__auto_type` there?)
Since my goal is to only allow `__auto_type` in C-compatible contexts, this should be prohibited, but wasn't.  Fixed.  (Any other cases I haven't thought of?)

================
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;
----------------
rsmith wrote:
> That would be ill-formed; revert this change.
Fixed.  Durr.

================
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();
----------------
rsmith wrote:
> 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).
My goal was to do the former; if you'd prefer to just make it a synonym.  In this case, the patch prevents `__auto_type` from being used in lambda parameters elsewhere.


http://reviews.llvm.org/D12686