Is there any chance we also add this patch to version 15?

Add left alignment test

Use endsSequence to match the pattern

In this case, I think it's dereferencing a pointer instead of multiplying two numbers.

Annotate * as UnaryOperator instead of PointerOrReference

Remove redundant code.

Right, I think we can fix this in the same way. I'll look into it soon.

I think we can also add new test cases in clang/unittests/Format/TokenAnnotatorTest.cpp.

Good point!

I think we cannot identify struct, union, class or enum by the right bracket. Clang-format will split the input into multiple lines. For instance struct Tmp {} *tmp; will be separated as struct Tmp { and } *tmp;. In annotating, we only handle the relation of tokens in a single line, so we cannot know whether } belongs to struct or not.

• modify option names
• only allow driver-defined macros used in cc1

I added two flags, -driver-define and -driver-undefine, to indicate macros that the driver defines. And I moved driver-defined macros from <command line> file to <built-in> file, like

Sorry, I didn't consider some cases. I'll fix it soon!

Sorry, I don't have commit access. @HazardyKnusperkeks, could you help me commit it?

Got it. Thanks for your reply!

Hi. I passed the unit tests on my computer. But the build status here is failed. The build log only shows the issue is related to git reset --hard. So, I don't know where the bug is. Could you give me some hints to fix this issue? Thanks!

Right. It looks better.

I have added a variable for MatchingLBrace->getPreviousNonComment().

Thanks for your reply! I added comments for each clause.

Just like mentioned above, UnwrappedLineParser will split the input into multiple lines. And MatchingParen will be reset before annotating(code). So when defining a struct, union, or class, the MatchingParen of the right brace will be NULL. If we want to access the left matching brace from the right brace, we need to add new member data, which saves the address of the left brace token, in class FormatToken.
In my opinion, it will be too complicated. Instead of MatchingParen, I categorize the tokens by checking whether it is a template because && will be a binary operator only in a template. In the other cases, && is likely a reference operator.

Add Left/Middle/Right alignment test cases.

• Add annotator test
• Add formatting test
• Handle reference cases by PrevToken->MatchingParen

I think it's a good idea. When does MatchingParen bind? The value of PrevToken->MatchingParen is still NULL in determineStarAmpUsage function.