[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