[PATCH] D42729: clang-format: Fix formatting of function body followed by semicolon

Daniel Jasper via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 28 07:08:39 PST 2018


djasper added a comment.

In https://reviews.llvm.org/D42729#1022069, @Typz wrote:

> In https://reviews.llvm.org/D42729#994841, @djasper wrote:
>
> > - Of course you find all sorts of errors while testing clang-format on a large-enough codebase. That doesn't mean that users run into them much.
> > - We have had about 10k clang-format users internally for several years. The semicolon issue comes up but really rarely and if it does, people happily fix their code not blaming clang-format.
> >
> >   Unrelated, my point remains that setting BlockKind in TokenAnnotator is bad enough that I wouldn't want to do it for reaping this small benefit. And I can't see how you could easily achieve the same thing without doing that.
>
>
> Just a question though. I there a reason brace matching (and other parts of TokenAnnotations) are not performed before LineUnwrapping? That would probably allow fixing this issue more cleanly (though I am not sure I would have the time to actually perform this probably significant task)...


I think this is just the way it has grown. And brace/paren matching is actually done in both places several times by now, I think :(.

Fundamentally, the UnwrappedLineParser had the task of splitting a source file into lines and only implemented what it needed for that. The TokenAnnotator then did a much more elaborate analysis on each line to determine token types and such and distinguish what a "<" actually is (comparison vs. template opener). Having these two things be separate makes it slightly easier for error recovery and such as the state space they can be in is somewhat more limited.


Repository:
  rC Clang

https://reviews.llvm.org/D42729





More information about the cfe-commits mailing list