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

[Nicholas Allegra via cfe-commits]

comex updated this revision to Diff 39838.
comex marked 16 inline comments as done.

http://reviews.llvm.org/D12686

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/DeclSpec.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/Format/TokenAnnotator.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseObjc.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
  test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p7-1y.cpp
  test/Sema/auto-type.c
  test/Sema/bitfield.c
  test/Sema/exprs.c
  test/SemaCXX/auto-type-from-cxx.cpp
  test/SemaCXX/cxx98-compat.cpp

Index: test/SemaCXX/cxx98-compat.cpp
===
--- test/SemaCXX/cxx98-compat.cpp
+++ test/SemaCXX/cxx98-compat.cpp
@@ -100,6 +100,9 @@
 };
 
 auto f() -> int; // expected-warning {{trailing return types are incompatible with C++98}}
+#ifdef CXX14COMPAT
+auto ff() { return 5; } // expected-warning {{'auto' type specifier is incompatible with C++98}}
+#endif
 
 void RangeFor() {
   int xs[] = {1, 2, 3};
Index: test/SemaCXX/auto-type-from-cxx.cpp
===
--- /dev/null
+++ test/SemaCXX/auto-type-from-cxx.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+struct A {
+operator __auto_type() {} // expected-error {{'__auto_type' not allowed in conversion function type}}
+};
+
+__auto_type a() -> int; // expected-error {{'__auto_type' not allowed in function return type}}
+template 
+__auto_type b() { return T::x; } // expected-error {{'__auto_type' not allowed in function return type}}
+auto c() -> __auto_type { __builtin_unreachable(); } // expected-error {{'__auto_type' not allowed in function return type}}
+int d() {
+  decltype(__auto_type) e = 1; // expected-error {{expected expression}}
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };
+  __auto_type h = BitField{1}.field; // (should work from C++)
+  new __auto_type; // expected-error {{'__auto_type' not allowed in type allocated by 'new'}}
+}
+
Index: test/Sema/exprs.c
===
--- test/Sema/exprs.c
+++ test/Sema/exprs.c
@@ -97,6 +97,7 @@
   R = __alignof(P->x);  // expected-error {{invalid application of 'alignof' to bit-field}}
   R = __alignof(P->y);   // ok.
   R = sizeof(P->x); // expected-error {{invalid application of 'sizeof' to bit-field}}
+  __extension__ ({ R = (__typeof__(P->x)) 2; }); // expected-error {{invalid application of 'typeof' to bit-field}}
   return R;
 }
 
Index: test/Sema/bitfield.c
===
--- test/Sema/bitfield.c
+++ test/Sema/bitfield.c
@@ -63,7 +63,8 @@
 typedef signed Signed;
 
 struct Test5 { unsigned n : 2; } t5;
-typedef __typeof__(t5.n) Unsigned; // Bitfield is unsigned
+// Bitfield is unsigned
+struct Test5 sometest5 = {-1}; // expected-warning {{implicit truncation from 'int' to bitfield changes value from -1 to 3}}
 typedef __typeof__(+t5.n) Signed;  // ... but promotes to signed.
 
 typedef __typeof__(t5.n + 0) Signed; // Arithmetic promotes.
Index: test/Sema/auto-type.c
===
--- /dev/null
+++ test/Sema/auto-type.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -std=c11
+
+__auto_type a = 5; // expected-warning {{'__auto_type' is a GNU extension}}
+__extension__ __auto_type a1 = 5;
+#pragma clang diagnostic ignored "-Wgnu-auto-type"
+__auto_type b = 5.0;
+__auto_type c = 
+__auto_type d = (struct {int a;}) {5};
+_Static_assert(__builtin_types_compatible_p(__typeof(a), int), "");
+__auto_type e = e; // expected-error {{variable 'e' declared with '__auto_type' type cannot appear in its own initializer}}
+
+struct s { __auto_type a; }; // expected-error {{'__auto_type' not allowed in struct member}}
+
+__auto_type f = 1, g = 1.0; // expected-error {{'__auto_type' deduced as 'int' in declaration of 'f' and deduced as 'double' in declaration of 'g'}}
+
+__auto_type h() {} // expected-error {{'__auto_type' not allowed in function return type}}
+
+int i() {
+  struct bitfield { int field:2; };
+  __auto_type j = (struct bitfield){1}.field; // expected-error {{cannot pass 

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

[Nicholas Allegra via cfe-commits]

comex added a comment.

Addressed comments.  Thanks, rsmith!



Comment at: lib/Sema/SemaType.cpp:3756-3760
@@ -3743,2 +3755,7 @@
   }
+} else if (D.getDeclSpec().getTypeSpecType() == 
DeclSpec::TST_auto_type) {
+  S.Diag(D.getDeclSpec().getTypeSpecTypeLoc(),
+ diag::err_auto_not_allowed)
+<< 2 << 13 << D.getDeclSpec().getSourceRange();
+  D.setInvalidType(true);
 }

rsmith wrote:
> Please deal with this in the "checking for auto" block at the top rather than 
> repeating the diagnostic code here with magic numbers; maybe change
> 
>   (!SemaRef.getLangOpts().CPlusPlus11 || !D.isFunctionDeclarator())) {
> 
> to
> 
>   (!SemaRef.getLangOpts().CPlusPlus11 || !D.isFunctionDeclarator() || 
> D.getDeclSpec().getTypeSpecType() == DeclSpec::TST_auto_type)) {
> 
> up there.
For the sake of clarity, I removed that whole bit from the if condition instead 
and moved the C++11 test down to where it sets `Error`.  Two bits of fallout 
from this:
- `typedef decltype(auto) f();` gets diagnosed there rather than later with a 
different error; I updated the test, since both errors seem reasonable.
- A bug is fixed where definitions like `auto f() { return 5; }` were not being 
caught with `-std=c++14 -Wc++98-compat`.  I updated the c++98-compat test to 
add this case.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Richard Smith via cfe-commits]

rsmith accepted this revision.
rsmith added a reviewer: rsmith.
rsmith added a comment.
This revision is now accepted and ready to land.

This LGTM, do you have SVN access or would you like someone to commit for you?



Comment at: lib/Sema/SemaType.cpp:2616-2618
@@ -2616,5 +2615,5 @@
   // C++11 [dcl.spec.auto]p5: reject 'auto' if it is not in an allowed context.
   // In C++11, a function declarator using 'auto' must have a trailing return
   // type (this is checked later) and we can skip this. In other languages
   // using auto, we need to check regardless.
   // C++14 In generic lambdas allow 'auto' in their parameters.

This comment is out of date. Delete these three lines?


Comment at: lib/Sema/SemaType.cpp:3767-3771
@@ -3743,7 +3766,7 @@
   }
 }
   }
 
   // C99 6.7.5.3p1: The return type may not be a function or array type.
   // For conversion functions, we'll diagnose this particular error later.
   if ((T->isArrayType() || T->isFunctionType()) &&

Does this change also fix PR25449?


Comment at: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p7-1y.cpp:52
@@ -51,3 +51,3 @@
 const decltype(auto) f4(); // expected-error {{'decltype(auto)' cannot be 
combined with other type specifiers}}
-typedef decltype(auto) f5(); // expected-error {{'decltype(auto)' can only be 
used as a return type in a function declaration}}
+typedef decltype(auto) f5(); // expected-error {{'decltype(auto)' not allowed 
in typedef}}
 decltype(auto) ((f6())); // ok

Thanks, this new diagnostic is a lot better :)


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Richard Smith via cfe-commits]

rsmith added inline comments.


Comment at: lib/Sema/SemaType.cpp:2621
@@ -2620,3 +2620,3 @@
   // C++14 In generic lambdas allow 'auto' in their parameters.
-  if (ContainsPlaceholderType &&
+  if (D.getDeclSpec().containsPlaceholderType() &&
   (!SemaRef.getLangOpts().CPlusPlus11 || !D.isFunctionDeclarator())) {

rsmith wrote:
> Does this still do the right thing for the `IK_ConversionFunctionId` case? It 
> doesn't look like it will: in that case, the `auto` is in the 
> //declarator-id//, not in the //decl-specifier-seq//.
Disregard this comment; I tried to delete it but it looks like phabricator 
submitted it anyway.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Richard Smith via cfe-commits]

rsmith added a comment.

Sorry for the long delay. This looks to be in good shape.



Comment at: include/clang/AST/Type.h:1210
@@ +1209,3 @@
+/// Which keyword(s) were used to create an AutoType.
+enum class AutoTypeKeyword : unsigned char {
+  /// \brief auto

The explicit underlying type here doesn't seem necessary.


Comment at: include/clang/AST/Type.h:1438
@@ -1429,1 +1437,3 @@
+/// Was this placeholder type spelled as 'auto', 'decltype(auto)', or 
'__auto_type'?
+AutoTypeKeyword Keyword : 2;
   };

Use `unsigned` not `AutoTypeKeyword`. MSVC struct layout inserts extra padding 
if your bit-fields don't all have the same type.


Comment at: include/clang/Basic/DiagnosticSemaKinds.td:1678
@@ -1674,3 +1677,3 @@
   "|in template argument|in typedef|in type alias|in function return type"
-  "|in conversion function type|here|in lambda parameter}1">;
+  "|in conversion function type|here|in lambda parameter|in 'new' argument}1">;
 def err_auto_not_allowed_var_inst : Error<

How about "in type allocated by `new`" or similar? The type operand isn't 
really an argument.


Comment at: lib/Sema/SemaTemplateDeduction.cpp:4007-4012
@@ -4006,4 +4006,8 @@
 
   InitListExpr *InitList = dyn_cast(Init);
   if (InitList) {
+if (!getLangOpts().CPlusPlus) {
+  Diag(Loc, diag::err_auto_init_list_from_c);
+  return DAR_Failed;
+}
 for (unsigned i = 0, e = InitList->getNumInits(); i < e; ++i) {

Move this bailout to before we build the template parameter and substitute it 
into the type.


Comment at: lib/Sema/SemaTemplateDeduction.cpp:4011
@@ +4010,3 @@
+  Diag(Loc, diag::err_auto_init_list_from_c);
+  return DAR_Failed;
+}

Should be `DAR_FailedAlreadyDiagnosed` so the caller doesn't diagnose it again.


Comment at: lib/Sema/SemaType.cpp:1481
@@ -1479,3 +1480,3 @@
 // being analyzed (which tracks the invented type template parameter).
 if (declarator.getContext() == Declarator::LambdaExprParameterContext) {
   sema::LambdaScopeInfo *LSI = S.getCurLambda();

Can you move the `auto_type` case label lower to make this more obvious? (Put a 
`break` into the `if` and replace the `else` with fallthrough to avoid putting 
the label inside the `else`.)


Comment at: lib/Sema/SemaType.cpp:1517
@@ +1516,3 @@
+Result = Context.getAutoType(QualType(),
+ /*Keyword*/ AutoTypeKeyword::DecltypeAuto,
+ /*IsDependent*/ false);

The `/*Keyword*/` comment here doesn't add anything, thanks to your 
enumeration. Remove it and clang-format this line?


Comment at: lib/Sema/SemaType.cpp:2621
@@ -2620,3 +2620,3 @@
   // C++14 In generic lambdas allow 'auto' in their parameters.
-  if (ContainsPlaceholderType &&
+  if (D.getDeclSpec().containsPlaceholderType() &&
   (!SemaRef.getLangOpts().CPlusPlus11 || !D.isFunctionDeclarator())) {

Does this still do the right thing for the `IK_ConversionFunctionId` case? It 
doesn't look like it will: in that case, the `auto` is in the 
//declarator-id//, not in the //decl-specifier-seq//.


Comment at: lib/Sema/SemaType.cpp:2626-2627
@@ -2625,4 +2625,4 @@
 switch (D.getContext()) {
 case Declarator::KNRTypeListContext:
   llvm_unreachable("K type lists aren't allowed in C++");
 case Declarator::LambdaExprContext:

This is now reachable.


Comment at: lib/Sema/SemaType.cpp:3756-3760
@@ -3743,2 +3755,7 @@
   }
+} else if (D.getDeclSpec().getTypeSpecType() == 
DeclSpec::TST_auto_type) {
+  S.Diag(D.getDeclSpec().getTypeSpecTypeLoc(),
+ diag::err_auto_not_allowed)
+<< 2 << 13 << D.getDeclSpec().getSourceRange();
+  D.setInvalidType(true);
 }

Please deal with this in the "checking for auto" block at the top rather than 
repeating the diagnostic code here with magic numbers; maybe change

  (!SemaRef.getLangOpts().CPlusPlus11 || !D.isFunctionDeclarator())) {

to

  (!SemaRef.getLangOpts().CPlusPlus11 || !D.isFunctionDeclarator() || 
D.getDeclSpec().getTypeSpecType() == DeclSpec::TST_auto_type)) {

up there.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex added a comment.

(Ping?  I verified yesterday that the patch still applies and passes regression 
tests.)


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex added a comment.

One more ping.  As far as I know, everything has been addressed.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex added inline comments.


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;

rsmith wrote:
> Do you really want to allow `__auto_type` here? This is inconsistent with 
> what you do for return types.
Also a mistake.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

thakis wrote:
> Shouldn't this say "warning: __auto_type is a gnu extension" (since this uses 
> -std=c++14, not -std=gnu++14)?
Hmm... when I added `ext_auto_type` to the .td, I didn't notice the difference 
between Extension and ExtWarn.  Since the patch currently uses Extension, it 
won't warn by default, but will with `-pedantic`, `-Wgnu`, or 
`-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.

Is there an explicit policy on which extensions should be ExtWarn?  Looking at 
the rest of that file, ExtWarns seem to be mostly either (a) standardized 
extensions (which will warn if `-std` is too early) and (b) 'extensions' that 
are more like "Clang will accept your buggy code" than features.  Most GNU 
extensions are just Extension, so I think it makes sense to do the same for 
`__auto_type`.

I could update the C++ test to add `-pedantic`, but arguably it makes more 
sense to test the fact that the warning is not emitted by default.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex added inline comments.


Comment at: lib/Sema/SemaType.cpp:2675-2678
@@ -2671,5 +2674,6 @@
   break;
 case Declarator::ConversionIdContext:
-  if (!SemaRef.getLangOpts().CPlusPlus14)
-Error = 12; // conversion-type-id
+  if (!SemaRef.getLangOpts().CPlusPlus14 ||
+  D.getDeclSpec().getTypeSpecType() == DeclSpec::TST_auto_type)
+Error = 14; // conversion-type-id
   break;

(Clarification: The "also a mistake" comment was meant to be submitted earlier, 
but was left in the Phabricator draft state; I already fixed this.)


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nico Weber via cfe-commits]

thakis added inline comments.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

comex wrote:
> thakis wrote:
> > Shouldn't this say "warning: __auto_type is a gnu extension" (since this 
> > uses -std=c++14, not -std=gnu++14)?
> Hmm... when I added `ext_auto_type` to the .td, I didn't notice the 
> difference between Extension and ExtWarn.  Since the patch currently uses 
> Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, or 
> `-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.
> 
> Is there an explicit policy on which extensions should be ExtWarn?  Looking 
> at the rest of that file, ExtWarns seem to be mostly either (a) standardized 
> extensions (which will warn if `-std` is too early) and (b) 'extensions' that 
> are more like "Clang will accept your buggy code" than features.  Most GNU 
> extensions are just Extension, so I think it makes sense to do the same for 
> `__auto_type`.
> 
> I could update the C++ test to add `-pedantic`, but arguably it makes more 
> sense to test the fact that the warning is not emitted by default.
I'm not sure either. `typeof` warns with -std=c++14 but not with -std=gnu++14. 
From a user perspective, this makes sense to me: I want to write standard c++ 
and I want the compiler to help me with that, but I don't want to get all the 
pedantic warnings that -pedantic entails. For example, consider using clang-cl 
to build Windows code, and wanting MSVC to be able to build said Windows code 
too. (This can of course go wrong with standard C++ too, but in that case I'm 
running into MSVC bugs which will eventually be fixed.) So if it's possible to 
match how typeof works, I think that'd be good. If it's not possible, this 
wouldn't be the only GNU extension allowed in -std=c++14 mode though, so it's 
not a big thing.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex added inline comments.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

thakis wrote:
> comex wrote:
> > thakis wrote:
> > > Shouldn't this say "warning: __auto_type is a gnu extension" (since this 
> > > uses -std=c++14, not -std=gnu++14)?
> > Hmm... when I added `ext_auto_type` to the .td, I didn't notice the 
> > difference between Extension and ExtWarn.  Since the patch currently uses 
> > Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, or 
> > `-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.
> > 
> > Is there an explicit policy on which extensions should be ExtWarn?  Looking 
> > at the rest of that file, ExtWarns seem to be mostly either (a) 
> > standardized extensions (which will warn if `-std` is too early) and (b) 
> > 'extensions' that are more like "Clang will accept your buggy code" than 
> > features.  Most GNU extensions are just Extension, so I think it makes 
> > sense to do the same for `__auto_type`.
> > 
> > I could update the C++ test to add `-pedantic`, but arguably it makes more 
> > sense to test the fact that the warning is not emitted by default.
> I'm not sure either. `typeof` warns with -std=c++14 but not with 
> -std=gnu++14. From a user perspective, this makes sense to me: I want to 
> write standard c++ and I want the compiler to help me with that, but I don't 
> want to get all the pedantic warnings that -pedantic entails. For example, 
> consider using clang-cl to build Windows code, and wanting MSVC to be able to 
> build said Windows code too. (This can of course go wrong with standard C++ 
> too, but in that case I'm running into MSVC bugs which will eventually be 
> fixed.) So if it's possible to match how typeof works, I think that'd be 
> good. If it's not possible, this wouldn't be the only GNU extension allowed 
> in -std=c++14 mode though, so it's not a big thing.
As far as I can tell, `typeof` doesn't warn at all.  In standard mode it's an 
*error* because `typeof` is treated as a normal identifier (so that code that 
uses it as such doesn't break), but if you use the reserved-namespace keyword 
`__typeof`, there is no warning even with `-Weverything`.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nico Weber via cfe-commits]

thakis added inline comments.


Comment at: test/SemaCXX/auto-type-from-cxx.cpp:14
@@ +13,3 @@
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed 
in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };

comex wrote:
> thakis wrote:
> > comex wrote:
> > > thakis wrote:
> > > > Shouldn't this say "warning: __auto_type is a gnu extension" (since 
> > > > this uses -std=c++14, not -std=gnu++14)?
> > > Hmm... when I added `ext_auto_type` to the .td, I didn't notice the 
> > > difference between Extension and ExtWarn.  Since the patch currently uses 
> > > Extension, it won't warn by default, but will with `-pedantic`, `-Wgnu`, 
> > > or `-Wgnu-auto-type`.  The C test uses `-pedantic` so it gets the warning.
> > > 
> > > Is there an explicit policy on which extensions should be ExtWarn?  
> > > Looking at the rest of that file, ExtWarns seem to be mostly either (a) 
> > > standardized extensions (which will warn if `-std` is too early) and (b) 
> > > 'extensions' that are more like "Clang will accept your buggy code" than 
> > > features.  Most GNU extensions are just Extension, so I think it makes 
> > > sense to do the same for `__auto_type`.
> > > 
> > > I could update the C++ test to add `-pedantic`, but arguably it makes 
> > > more sense to test the fact that the warning is not emitted by default.
> > I'm not sure either. `typeof` warns with -std=c++14 but not with 
> > -std=gnu++14. From a user perspective, this makes sense to me: I want to 
> > write standard c++ and I want the compiler to help me with that, but I 
> > don't want to get all the pedantic warnings that -pedantic entails. For 
> > example, consider using clang-cl to build Windows code, and wanting MSVC to 
> > be able to build said Windows code too. (This can of course go wrong with 
> > standard C++ too, but in that case I'm running into MSVC bugs which will 
> > eventually be fixed.) So if it's possible to match how typeof works, I 
> > think that'd be good. If it's not possible, this wouldn't be the only GNU 
> > extension allowed in -std=c++14 mode though, so it's not a big thing.
> As far as I can tell, `typeof` doesn't warn at all.  In standard mode it's an 
> *error* because `typeof` is treated as a normal identifier (so that code that 
> uses it as such doesn't break), but if you use the reserved-namespace keyword 
> `__typeof`, there is no warning even with `-Weverything`.
Ah, ok. That's ok as-is then. It'd be nice if there was something that warning 
on GNU extensions, but that's independent of this patch :-)


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex added a comment.

Ping again.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Richard Smith via cfe-commits]

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 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(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



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Vedant Kumar via cfe-commits]

vsk added a comment.

This lgtm. If you don't have commit rights, I can land this for you if you'd 
like.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Richard Smith via cfe-commits]

rsmith added a comment.

Thanks, this essentially looks good to me. I can't think of any other cases 
where C++ allows `auto` that you've not covered.



Comment at: lib/Sema/SemaExprCXX.cpp:1172-1173
@@ -1171,1 +1171,4 @@
 
+  if (D.getDeclSpec().getTypeSpecType() == DeclSpec::TST_auto_type)
+  return ExprError(Diag(StartLoc, diag::err_new_auto_type));
+

How about instead handling this...


Comment at: lib/Sema/SemaType.cpp:2687
@@ -2682,3 +2686,3 @@
 case Declarator::ConditionContext:
 case Declarator::CXXNewContext:
   break;

... here.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex updated the summary for this revision.
comex updated this revision to Diff 37202.
comex marked 3 inline comments as done.
comex added a comment.

Fixed raised issues.

(I don't have commit rights.)


http://reviews.llvm.org/D12686

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/DeclSpec.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/Format/TokenAnnotator.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseObjc.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
  test/Sema/auto-type.c
  test/Sema/bitfield.c
  test/Sema/exprs.c
  test/SemaCXX/auto-type-from-cxx.cpp

Index: test/SemaCXX/auto-type-from-cxx.cpp
===
--- /dev/null
+++ test/SemaCXX/auto-type-from-cxx.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+struct A {
+operator __auto_type() {} // expected-error {{'__auto_type' not allowed in conversion function type}}
+};
+
+__auto_type a() -> int; // expected-error {{function with trailing return type must specify return type 'auto', not '__auto_type'}}
+template 
+__auto_type b() { return T::x; } // expected-error {{'__auto_type' not allowed in function return type}}
+auto c() -> __auto_type { __builtin_unreachable(); } // expected-error {{'__auto_type' not allowed in function return type}}
+int d() {
+  decltype(__auto_type) e = 1; // expected-error {{expected expression}}
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };
+  __auto_type h = BitField{1}.field; // (should work from C++)
+  new __auto_type; // expected-error {{cannot use '__auto_type' as 'new' type}}
+}
+
Index: test/Sema/exprs.c
===
--- test/Sema/exprs.c
+++ test/Sema/exprs.c
@@ -97,6 +97,7 @@
   R = __alignof(P->x);  // expected-error {{invalid application of 'alignof' to bit-field}}
   R = __alignof(P->y);   // ok.
   R = sizeof(P->x); // expected-error {{invalid application of 'sizeof' to bit-field}}
+  __extension__ ({ R = (__typeof__(P->x)) 2; }); // expected-error {{invalid application of 'typeof' to bit-field}}
   return R;
 }
 
Index: test/Sema/bitfield.c
===
--- test/Sema/bitfield.c
+++ test/Sema/bitfield.c
@@ -63,7 +63,8 @@
 typedef signed Signed;
 
 struct Test5 { unsigned n : 2; } t5;
-typedef __typeof__(t5.n) Unsigned; // Bitfield is unsigned
+// Bitfield is unsigned
+struct Test5 sometest5 = {-1}; // expected-warning {{implicit truncation from 'int' to bitfield changes value from -1 to 3}}
 typedef __typeof__(+t5.n) Signed;  // ... but promotes to signed.
 
 typedef __typeof__(t5.n + 0) Signed; // Arithmetic promotes.
Index: test/Sema/auto-type.c
===
--- /dev/null
+++ test/Sema/auto-type.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -std=c11
+
+__auto_type a = 5; // expected-warning {{'__auto_type' is a GNU extension}}
+__extension__ __auto_type a1 = 5;
+#pragma clang diagnostic ignored "-Wgnu-auto-type"
+__auto_type b = 5.0;
+__auto_type c = 
+__auto_type d = (struct {int a;}) {5};
+_Static_assert(__builtin_types_compatible_p(__typeof(a), int), "");
+__auto_type e = e; // expected-error {{variable 'e' declared with '__auto_type' type cannot appear in its own initializer}}
+
+struct s { __auto_type a; }; // expected-error {{'__auto_type' not allowed in struct member}}
+
+__auto_type f = 1, g = 1.0; // expected-error {{'__auto_type' deduced as 'int' in declaration of 'f' and deduced as 'double' in declaration of 'g'}}
+
+__auto_type h() {} // expected-error {{'__auto_type' not allowed in function return type}}
+
+int i() {
+  struct bitfield { int field:2; };
+  __auto_type j = (struct bitfield){1}.field; // expected-error {{cannot pass bit-field as __auto_type initializer in C}}
+
+}
Index: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
===
--- test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
+++ test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
@@ -3,9 +3,9 @@
 
 // FIXME: This is in p11 (?) in C++1y.
 void f() {
-  

Re: [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 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



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex updated this revision to Diff 37215.
comex added a comment.

Okay.


http://reviews.llvm.org/D12686

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/DeclSpec.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/Format/TokenAnnotator.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseObjc.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
  test/Sema/auto-type.c
  test/Sema/bitfield.c
  test/Sema/exprs.c
  test/SemaCXX/auto-type-from-cxx.cpp

Index: test/SemaCXX/auto-type-from-cxx.cpp
===
--- /dev/null
+++ test/SemaCXX/auto-type-from-cxx.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+struct A {
+operator __auto_type() {} // expected-error {{'__auto_type' not allowed in conversion function type}}
+};
+
+__auto_type a() -> int; // expected-error {{function with trailing return type must specify return type 'auto', not '__auto_type'}}
+template 
+__auto_type b() { return T::x; } // expected-error {{'__auto_type' not allowed in function return type}}
+auto c() -> __auto_type { __builtin_unreachable(); } // expected-error {{'__auto_type' not allowed in function return type}}
+int d() {
+  decltype(__auto_type) e = 1; // expected-error {{expected expression}}
+  auto _ = [](__auto_type f) {}; // expected-error {{'__auto_type' not allowed in lambda parameter}}
+  __auto_type g = 2;
+  struct BitField { int field:2; };
+  __auto_type h = BitField{1}.field; // (should work from C++)
+  new __auto_type; // expected-error {{'__auto_type' not allowed in 'new' argument}}
+}
+
Index: test/Sema/exprs.c
===
--- test/Sema/exprs.c
+++ test/Sema/exprs.c
@@ -97,6 +97,7 @@
   R = __alignof(P->x);  // expected-error {{invalid application of 'alignof' to bit-field}}
   R = __alignof(P->y);   // ok.
   R = sizeof(P->x); // expected-error {{invalid application of 'sizeof' to bit-field}}
+  __extension__ ({ R = (__typeof__(P->x)) 2; }); // expected-error {{invalid application of 'typeof' to bit-field}}
   return R;
 }
 
Index: test/Sema/bitfield.c
===
--- test/Sema/bitfield.c
+++ test/Sema/bitfield.c
@@ -63,7 +63,8 @@
 typedef signed Signed;
 
 struct Test5 { unsigned n : 2; } t5;
-typedef __typeof__(t5.n) Unsigned; // Bitfield is unsigned
+// Bitfield is unsigned
+struct Test5 sometest5 = {-1}; // expected-warning {{implicit truncation from 'int' to bitfield changes value from -1 to 3}}
 typedef __typeof__(+t5.n) Signed;  // ... but promotes to signed.
 
 typedef __typeof__(t5.n + 0) Signed; // Arithmetic promotes.
Index: test/Sema/auto-type.c
===
--- /dev/null
+++ test/Sema/auto-type.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -std=c11
+
+__auto_type a = 5; // expected-warning {{'__auto_type' is a GNU extension}}
+__extension__ __auto_type a1 = 5;
+#pragma clang diagnostic ignored "-Wgnu-auto-type"
+__auto_type b = 5.0;
+__auto_type c = 
+__auto_type d = (struct {int a;}) {5};
+_Static_assert(__builtin_types_compatible_p(__typeof(a), int), "");
+__auto_type e = e; // expected-error {{variable 'e' declared with '__auto_type' type cannot appear in its own initializer}}
+
+struct s { __auto_type a; }; // expected-error {{'__auto_type' not allowed in struct member}}
+
+__auto_type f = 1, g = 1.0; // expected-error {{'__auto_type' deduced as 'int' in declaration of 'f' and deduced as 'double' in declaration of 'g'}}
+
+__auto_type h() {} // expected-error {{'__auto_type' not allowed in function return type}}
+
+int i() {
+  struct bitfield { int field:2; };
+  __auto_type j = (struct bitfield){1}.field; // expected-error {{cannot pass bit-field as __auto_type initializer in C}}
+
+}
Index: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
===
--- test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
+++ test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
@@ -3,9 +3,9 @@
 
 // FIXME: This is in p11 (?) in C++1y.
 void f() {
-  decltype(auto) a = a; // expected-error{{variable 'a' declared with 'auto' type cannot appear in its own initializer}}
-  if (decltype(auto) b = b) {} // 

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

[Vedant Kumar via cfe-commits]

vsk added a subscriber: vsk.
vsk added a comment.

First off, welcome! And thanks for patch.

This basically LGTM, but I have one small change I'd like to see (inline 
comment).

Hm, the spec says "The sizeof operator shall not be applied to... an lvalue 
that designates a bit-field". Sounds like a bug to me.



Comment at: lib/Sema/SemaType.cpp:2698
@@ -2693,1 +2697,3 @@
+  const unsigned Keyword =
+  D.getDeclSpec().getTypeSpecType() - DeclSpec::TST_auto;
   SemaRef.Diag(AutoRange.getBegin(), diag::err_auto_not_allowed)

Hm, this is a little hard to read. IIUC it's also sensitive to re-ordering of 
enum values. I'd be happier if you introduced a switch here, and made the LHS 
enum type explicit.


Comment at: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp:4
@@ -3,3 +3,3 @@
 
 // FIXME: This is in p11 (?) in C++1y.
 void f() {

Do you know what this FIXME alludes to? Seems rather mysterious to me.


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Richard Smith via cfe-commits]

rsmith added a subscriber: rsmith.


Comment at: include/clang/AST/Type.h:1210
@@ +1209,3 @@
+/// Which keyword(s) were used to create an AutoType.
+enum struct AutoTypeKeyword : unsigned char {
+  /// \brief auto

Please use `enum class` here; we don't use `enum struct` anywhere in Clang or 
LLVM.


Comment at: include/clang/AST/Type.h:1216
@@ +1215,3 @@
+  /// \brief __auto_type (GNU extension)
+  AutoTypeExt
+};

Maybe `GNUAutoType`?


Comment at: include/clang/AST/Type.h:3915-3916
@@ -3902,5 +3914,4 @@
 
   void Profile(llvm::FoldingSetNodeID ) {
-Profile(ID, getDeducedType(), isDecltypeAuto(), 
-   isDependentType());
+Profile(ID, getDeducedType(), AutoTypeBits.Keyword, isDependentType());
   }

`auto` and `__auto_type` should probably not profile differently; they mangle 
the same, so this will lead to mangling collisions. (It's not completely clear 
that we need to retain the distinction between `auto` and `__auto_type` here at 
all, since they have identical semantics, but it's probably a good thing for 
source fidelity. We don't maintain a difference between `bool` and `_Bool`, for 
what it's worth.)


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

`const AutoType* AT` -> const AutoType *AT`. Also, remove the unnecessary 
`.getTypePtr()` here.


Comment at: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp:4
@@ -3,3 +3,3 @@
 
 // FIXME: This is in p11 (?) in C++1y.
 void f() {

vsk wrote:
> Do you know what this FIXME alludes to? Seems rather mysterious to me.
It says that the relevant wording in the standard got moved to a different 
paragraph number (due to the insertion of more rules beforehand for deduced 
return types and generic lambdas).


http://reviews.llvm.org/D12686



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nicholas Allegra via cfe-commits]

comex created this revision.
comex added a subscriber: cfe-commits.
Herald added subscribers: aemerson, klimek.

Add support for GCC's '__auto_type' extension.

As per the GCC manual: https://gcc.gnu.org/onlinedocs/gcc/Typeof.html

Implemented in GCC 4.9, __auto_type is similar to C++11 auto but works in C.
The most compelling use case is for macros; the above manual page explains the
need pretty well, so I won't repeat it here.

This implementation differs from GCC's in also supporting __auto_type in C++,
treating it the same as auto.  I don't see any good reason not to, because
otherwise headers intended to be used from both languages can't use it (you
could use a define that expands to '__auto_type' or 'auto' depending on the
language, but then C++ pre-11 is broken).  However, for sanity's sake, it
prevents using __auto_type instead of auto with C++11+-specific functionality
such as 'decltype(auto)', auto arguments to lambdas, and auto before a trailing
return type.

**It also differs by allowing all of the following (by default, due to reusing
the C++ auto behavior) which GCC rejects: initializing with the value of a bit
field, using '__auto_type *', and declaring multiple variables in one
statement.  (The first of those extends a preexisting difference: GCC does not
allow typeof on a bit field, while Clang currently does.  Arguably a bug, as
the C standard prohibits using sizeof on them.)  Maybe this should be tightened
for the sake of compatibility, although it doesn't otherwise seem harmful to
allow them (the latter two, anyway).  Opinions desired.

Making this work in clang is pretty straightforward: most of the patch is only
needed to fix up diagnostics.

(This is my first patch submission, so please let me know if I've done things
wrong.)


http://reviews.llvm.org/D12686

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/DeclSpec.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/Type.cpp
  lib/AST/TypePrinter.cpp
  lib/Format/TokenAnnotator.cpp
  lib/Parse/ParseDecl.cpp
  lib/Parse/ParseDeclCXX.cpp
  lib/Parse/ParseObjc.cpp
  lib/Parse/ParseTentative.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
  test/Sema/auto-type.c
  test/SemaCXX/auto-type-from-cxx.cpp

Index: test/SemaCXX/auto-type-from-cxx.cpp
===
--- /dev/null
+++ test/SemaCXX/auto-type-from-cxx.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify %s
+
+__auto_type a() -> int; // expected-error {{function with trailing return type must specify return type 'auto', not '__auto_type'}}
+int b() {
+  decltype(__auto_type) c = 1; // expected-error {{expected expression}}
+  auto _ = [](__auto_type d) {}; // expected-error {{'__auto_type' not allowed in lambda parameter}}
+  __auto_type e = 2;
+}
+
Index: test/Sema/auto-type.c
===
--- /dev/null
+++ test/Sema/auto-type.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -std=c11
+
+__auto_type a = 5; // expected-warning {{'__auto_type' is a GNU extension}}
+__extension__ __auto_type a1 = 5;
+#pragma clang diagnostic ignored "-Wgnu-auto-type"
+__auto_type b = 5.0;
+__auto_type c = 
+__auto_type d = (struct {int a;}) {5};
+_Static_assert(__builtin_types_compatible_p(__typeof(a), int), "");
+__auto_type e = e; // expected-error {{variable 'e' declared with '__auto_type' type cannot appear in its own initializer}}
+
+struct s { __auto_type a; }; // expected-error {{'__auto_type' not allowed in struct member}}
+
+__auto_type f = 1, g = 1.0; // expected-error {{'__auto_type' deduced as 'int' in declaration of 'f' and deduced as 'double' in declaration of 'g'}}
+
+__auto_type a() {} // expected-error {{'__auto_type' not allowed in function return type}}
Index: test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
===
--- test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
+++ test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-1y.cpp
@@ -3,9 +3,9 @@
 
 // FIXME: This is in p11 (?) in C++1y.
 void f() {
-  decltype(auto) a = a; // expected-error{{variable 'a' declared with 'auto' type cannot appear in its own initializer}}
-  if (decltype(auto) b = b) {} // expected-error {{variable 'b' declared with 'auto' type cannot appear in its own initializer}}
-  decltype(auto) c = ({ decltype(auto) d = c; 0; }); // expected-error {{variable