In rG1e0709167f5edd330889f51bb203c458bdb5e359#1183439, @krasimir wrote:

In rG1e0709167f5edd330889f51bb203c458bdb5e359#1182790, @ChuanqiXu wrote:

It will be helpful if you can provide a reproducer or a reproducer command.

We're looking into this. We are hitting this in a large modules build and it's taking up some effort to reduce.

In rG1e0709167f5edd330889f51bb203c458bdb5e359#1182790, @ChuanqiXu wrote:

It will be helpful if you can provide a reproducer or a reproducer command.

I submitted https://github.com/llvm/llvm-project/commit/8227349f7e4f1a6ceb4cceb464c8f4420ff1dd0a to address errors we started seeing in <optional> after this. Leaving a comment here so the author can take a look and check if this is reasonable.

Thank you!

Was it actually a regression or did this patch also fix a bug? It seems that the continuation indent before the & in your example is inconsistent with other similar function declarations.

It looks like this regressed the following example:

% cat test.cc  # formatted with older clang-format
aaaaaaaaaaaaaaaaaaaaaaaaa<bbbbbbbbbbb>
    &cccccccccccccccccccccccccccccccccccccc() {
  return 1;
}
% clang-format --version
clang-format version 16.0.0 (https://github.com/llvm/llvm-project.git a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f)
% clang-format -style=google test.cc
aaaaaaaaaaaaaaaaaaaaaaaaa<bbbbbbbbbbb> &
cccccccccccccccccccccccccccccccccccccc() {
  return 1;
}
%

I'll submit this for you.

In D129771#3653830, @jackhong12 wrote:

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

Tokens = annotate("int i = int{42} * 34;");
...

• address review comments

Proposed https://reviews.llvm.org/D129771.

In D127873#3651364, @jackhong12 wrote:

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.

Appears that this regressed examples like this:

// before
int i = int{16} * 1024;
// after
int i = int{16}* 1024;

Naively it looks like in all added examples, the token preceding the matching { of the } is one of struct, class, union, enum, or a >. Could we adapt this heuristic to only apply TT_PointerOrReference in cases like this?

We found another regression with this in wrongly indenting/not putting on its own line ObjC @interface:

% ./clang-format --version           
clang-format version 15.0.0 (https://github.com/llvm/llvm-project.git 50cd52d9357224cce66a9e00c9a0417c658a5655)
% cat test.m
NS_SWIFT_NAME(A)
@interface B : C
@property(readonly) D value;
@end

It looks like this regressed the following example by adding an unwanted level of indentation to the #elif B branch:

% ./clang-format --version
clang-format version 15.0.0 (https://github.com/llvm/llvm-project.git 50cd52d9357224cce66a9e00c9a0417c658a5655)
% cat test.cc             
#define MACRO_BEGIN

In D121370#3488401, @kwk wrote:

@krasimir could you please test this patch on your side?

@kwk thank you! the new version of the patch looks good!

• update with just the last commit

@krasimir I'm on sick leave and will have a look as soon as I'm back. Can it wait that long?

It appears that this regressed include sorting in the following case, where the contents of test.h show the expected include order and the clang-format behavior before this patch:

% cat test.h
#include <cstdint>

It appears that this regressed some ObjC patterns:

So I'd rather keep the old behaviour for # in Proto but not in C-like languages. Is that acceptable?

It appears that this regressed some ObjC patterns:

% cat test.m  # before: good
void f() {
  //
  BOOL a = [b.c count] > 1;
  int b = a;
}
% clang-format -style=google test.m  # after: bad, statements joined on the same line
void f() {
  //
  BOOL a = [b.c count] > 1; int b = a;
}
%

This is getting more fun: the reason why /// isn't broken up is because the first character / after the comment leader // is considered punctuation per isPunctuation's CHAR_RAWDEL, which includes all these {}[]#<>%:;?*+-/^&|~!=,"':

• https://github.com/llvm/llvm-project/blob/73a15ad567071c13e761fd6d593e2b66164865e2/clang/lib/Format/BreakableToken.cpp#L790
• https://github.com/llvm/llvm-project/blob/73a15ad567071c13e761fd6d593e2b66164865e2/clang/include/clang/Basic/CharInfo.h#L139
• https://github.com/llvm/llvm-project/blob/73a15ad567071c13e761fd6d593e2b66164865e2/clang/include/clang/Basic/CharInfo.h#L31

In D121451#3395611, @curdeius wrote:

In D121451#3395578, @krasimir wrote:

This appears to have broken a relatively common pattern we see in text proto comments where sections use a style like this:

################################################################################
# Big section name
################################################################################

That's a pity.
Do you think that just doing a different thing (what we had before) for Proto (and if possible other languages where # is used in a similar way) should be enough?

This appears to have broken a relatively common pattern we see in text proto comments where sections use a style like this:

################################################################################
# Big section name
################################################################################

Thank you!
Turns out the original source wasn't using an ascii space for the comment indentation but a unicode [c2 a0] no-break space:

2f 2f c2 a0 43 6f 6d 6d  65 6e 74 0a 69 6e 74 20  |//..Comment.int |

IMO we shouldn't aim to handle non-ascii spaces for indentation in clang-format; the new behavior on this example is fine.

It appears that this caused a regression by adding an additional space of indentation to line comments in some cases:

% cat test.cc  # (before)
// Comment
int i;
% clang-format -style=google test.cc
//  Comment
int i;

@ksyx could you please take a look?

I just pushed 6cb42cd6669785f3b611106e1b6b38bbe65733a9 to hopefully fix this.

@achieveartificialintelligence thank you for looking into this, sorry for the late reply!

In D93298#3342480, @achieveartificialintelligence wrote:

In D93298#3342452, @krasimir wrote:

@achieveartificialintelligence any progress with the problematic IR? Have you been able to reproduce using nikic's reduced example?

Sorry, I don't have a solution right now.

@achieveartificialintelligence any progress with the problematic IR? Have you been able to reproduce using nikic's reduced example?

Thank you!

• address review comments