[PATCH] D63260: [Attr] Support _attribute__ ((fallthrough))

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked 5 inline comments as done.
xbolva00 added inline comments.


================
Comment at: lib/Parse/ParseStmt.cpp:110-111
 
   assert((Attrs.empty() || Res.isInvalid() || Res.isUsable()) &&
          "attributes on empty statement");
 
----------------
nickdesaulniers wrote:
> Wouldn't this statement have to change? `__attribute__((fallthrough))` //is// an "attribute on [an] empty statement."  Maybe this is not the correct place to try to parse a GNU attr?
Since we parse [[ ]] parse here too, I expect it could be correct place.

@aaron.ballman ?


================
Comment at: lib/Sema/AnalysisBasedWarnings.cpp:1279
         continue;
-      if (S.getLangOpts().CPlusPlus11) {
+      if (S.getLangOpts().CPlusPlus11 || S.getLangOpts().C99) {
         const Stmt *Term = B->getTerminatorStmt();
----------------
nickdesaulniers wrote:
> Probably should additionally/instead check `S.getLangOpts().GNUMode` (since these are GNU C style attributes)?  I guess we want these attributes to be supported in C regardless of `-std=`?
Good point.


================
Comment at: test/Sema/block-literal.c:44
   takeblock(^{ x = 4; });  // expected-error {{variable is not assignable (missing __block type specifier)}}
-  __block y = 7;    // expected-warning {{type specifier missing, defaults to 'int'}}
-  takeblock(^{ y = 8; });
+  __block y = 7;    // expected-error {{use of undeclared identifier 'y'}}
+  takeblock(^{ y = 8; }); // expected-error {{use of undeclared identifier 'y'}}
----------------
nickdesaulniers wrote:
> xbolva00 wrote:
> > I tried look at this, but I have no idea how my change to parse GNU affects __block.
> If you remove your change to `lib/Parse/ParseStmt.cpp`, does this test still fail in this way?  Did you test this on an assertion enabled build (`-DLLVM_ENABLE_ASSERTIONS=ON`)? (I would have expected the assertion I commented on above to fail.)
Yes, added line "MaybeParseGNUAttributes(Attrs);" cause this changes in block-literal.c and address_spaces.c.


================
Comment at: test/Sema/block-literal.c:44
   takeblock(^{ x = 4; });  // expected-error {{variable is not assignable (missing __block type specifier)}}
-  __block y = 7;    // expected-warning {{type specifier missing, defaults to 'int'}}
-  takeblock(^{ y = 8; });
+  __block y = 7;    // expected-error {{use of undeclared identifier 'y'}}
+  takeblock(^{ y = 8; }); // expected-error {{use of undeclared identifier 'y'}}
----------------
xbolva00 wrote:
> nickdesaulniers wrote:
> > xbolva00 wrote:
> > > I tried look at this, but I have no idea how my change to parse GNU affects __block.
> > If you remove your change to `lib/Parse/ParseStmt.cpp`, does this test still fail in this way?  Did you test this on an assertion enabled build (`-DLLVM_ENABLE_ASSERTIONS=ON`)? (I would have expected the assertion I commented on above to fail.)
> Yes, added line "MaybeParseGNUAttributes(Attrs);" cause this changes in block-literal.c and address_spaces.c.
Yes, LLVM_ENABLE_ASSERTIONS is ticked in cmake-gui.. I have no assert failure in that place..


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63260/new/

https://reviews.llvm.org/D63260