User Details
- User Since
- Oct 11 2016, 5:32 AM (336 w, 5 d)
Wed, Mar 22
Mon, Mar 13
Fri, Mar 10
Thu, Mar 9
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.
Jan 25 2023
Jan 23 2023
Jan 16 2023
Thank you!
Jan 12 2023
Jan 11 2023
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.
Jan 10 2023
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; } %
Dec 16 2022
I'll submit this for you.
Dec 14 2022
Dec 13 2022
Nov 10 2022
Nov 8 2022
Aug 11 2022
Jul 15 2022
- address review comments
Jul 14 2022
Proposed https://reviews.llvm.org/D129771.
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?
Jun 15 2022
May 17 2022
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
May 16 2022
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
May 11 2022
May 3 2022
@kwk thank you! the new version of the patch looks good!
Apr 28 2022
Apr 27 2022
- 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?
Apr 25 2022
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>
Mar 24 2022
It appears that this regressed some ObjC patterns:
Mar 22 2022
So I'd rather keep the old behaviour for # in Proto but not in C-like languages. Is that acceptable?
Mar 21 2022
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
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 ################################################################################
Mar 16 2022
Mar 9 2022
Mar 4 2022
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?
Mar 3 2022
I just pushed 6cb42cd6669785f3b611106e1b6b38bbe65733a9 to hopefully fix this.
Mar 2 2022
@achieveartificialintelligence thank you for looking into this, sorry for the late reply!
Feb 24 2022
@achieveartificialintelligence any progress with the problematic IR? Have you been able to reproduce using nikic's reduced example?
Feb 22 2022
Thank you!
- address review comments