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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
