[PATCH] D64632: [clang-format] Don't detect call to ObjC class method as C++11 attribute specifier

Robbie Gibson via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jul 12 08:41:41 PDT 2019


rkgibson2 marked an inline comment as done.
rkgibson2 added a comment.

In D64632#1582793 <https://reviews.llvm.org/D64632#1582793>, @benhamilton wrote:

> Thanks for the fix. One question: how does the real Clang parser deal with this case? Is it something that's actually ambiguous in the ObjC++ grammar, I wonder?


I am not sure about real Clang. I actually don't know much about how it works. I just ran into this bug and wanted to see if it was fixable. My guess is the @ sign marks the bracket as an array literal. In clang-format, isCpp11AttributeSpecifier is checked before checking whether the previous token is @.



================
Comment at: clang/lib/Format/TokenAnnotator.cpp:400-413
     while (AttrTok && !AttrTok->startsSequence(tok::r_square, tok::r_square)) {
       // ObjC message send. We assume nobody will use : in a C++11 attribute
       // specifier parameter, although this is technically valid:
-      // [[foo(:)]]
+      // [[foo(:)]]. 'class' is a common ObjC method selector, so allow it as
+      // well.
       if (AttrTok->is(tok::colon) ||
           AttrTok->startsSequence(tok::identifier, tok::identifier) ||
----------------
benhamilton wrote:
> Maybe we should check the token before AttrTok to see if it's `tok::at`, rather than checking for an identifier followed by `tok::kw_class`?
> 
> I don't think there's any valid C++11 attribute specifier sequence of `@[[]]`.
> 
Ok, sure. I considered that at first but I'm not familiar with C++11 enough to say. I thought it wasn't valid, but I wasn't sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64632





More information about the cfe-commits mailing list