jrtc27 added inline comments.
================
Comment at: clang/lib/Format/TokenAnnotator.cpp:2874-2889
+ if (Left.is(TT_PointerOrReference)) {
+ if (Style.SpaceBeforePointerQualifiers &&
+ Right.canBePointerOrReferenceQualifier())
+ return true;
return Right.Tok.isLiteral() || Right.is(TT_BlockComment) ||
(Right.isOneOf(Keywords.kw_override, Keywords.kw_final) &&
!Right.is(TT_StartOfName)) ||
----------------
arichardson wrote:
> jrtc27 wrote:
> > arichardson wrote:
> > > jrtc27 wrote:
> > > >
> > > I feel like moving it here could in theory miss some cases. Also the
> > > condition is already barely comprehensible (I didn't attempt to
> > > understand which special cases all these conditions are for) and I don't
> > > feel like making it more complex.
> > >
> > > If clang-format has identified that this */& token is a
> > > pointer/reference, and the next token is something that can be paresed as
> > > a pointer qualifier, shouldn't we trust the parser and simply look at the
> > > format option? It also IMO makes the code slightly easier to understand.
> > It's a series of `A || B || C || ...`, and you just added an `if (X) return
> > true;` above, so changing it to `A || B || C || X || ...` is entirely
> > equivalent, no need to understand what any of the other expressions in the
> > giant OR are.
> Never mind, I thought your suggestion it was inside nested parens. It's
> equivalent just avoids the braces.
Uh of course with `||` added on the end of that new sub-expression, managed to
omit that...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D88227/new/
https://reviews.llvm.org/D88227
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
