benhamilton added inline comments.

Comment at: lib/Format/TokenAnnotator.cpp:155
+           Next->startsSequence(tok::identifier, tok::l_square,
+                                tok::numeric_constant, tok::r_square,
+                                tok::r_paren, tok::l_paren))) {
benhamilton wrote:
> djasper wrote:
> > benhamilton wrote:
> > > djasper wrote:
> > > > This seems suspect. Does it have to be a numeric_constant?
> > > Probably not, any constexpr would do, I suspect. What's the best way to 
> > > parse that?
> > I think this is the same answer for both of your questions. If what you are 
> > trying to prevent "FOO(^)" to be parsed as a block, wouldn't it be enough 
> > to look for whether there is a "(" after the ")" or even only after "(^)", 
> > everything else is already correct IIUC? That would get you out of need to 
> > parse the specifics here, which will be hard.
> > 
> > Or thinking about it another way. Previously, every "(^" would be parsed as 
> > an ObjC block. There seems to be only a really rare corner case in which it 
> > isn't (macros). Thus, I'd just try to detect that corner case. Instead you 
> > are completely inverting the defaults (defaulting to "^" is not a block) 
> > and then try to exactly parse ObjC where there might be many cases and edge 
> > cases that you won't even think of now.
> Hmm. Well, it's not just `FOO(^);` that isn't a block:
> ```
> #define FOO(X) operator X
> SomeType FOO(^)(int x, const SomeType& y) { ... }
> ```
> Obviously we can't get this perfect without a pre-processor, but it seems 
> like our best bet is to only assign mark `TT_ObjCBlockLParen` when we are 
> sure the syntax is a valid block type or block variable.
I tried the suggestion to only treat `(^)(` as a block type, but it appears 
this is the primary place where we set `TT_ObjCBlockLParen`, so I think we 
really do need to handle the other cases here.

  rC Clang

cfe-commits mailing list

Reply via email to