Wed, Jul 21
- Rename to libcpp_copysign due to clashes with Linux ::copysign. Add double overload.
Regarding naming, maybe I should rename __copysign to __libcpp_copysign to match what is done currently?
- Qualify calls.
Tue, Jul 20
Mon, Jul 19
I just reviewed the differences between K&R C (circa 1978) and ANSI/ISO C again and didn't see anything else that would impact clang-format, so a new Standard enum value for C78 is not needed. Nevertheless, we can add a boolean option e.g. C78ParameterDecl in the future if this patch causes regressions for some users. WDYT?
Fri, Jul 16
Looks okay, but I was wondering if we don't want to guard all K&R-related changes behind e.g. `Standard: Cpp78``, so as not to possibly introduce strange bugs in newer modes.
It may be an overkill if there are 2 patches like this, but if there are more, that might become sensible to do so.
Wed, Jul 14
I've been trying to make my opinion on this patch for the last few weeks...
I was pretty much opposed to introducing non-whitespace chances previously, but I'm reviewing my standpoint.
As mentioned already, there are precedents (include sorting, namespace comments, long string splitting).
I'm however even more wary of adding yet another tool that will be almost the same as clang-format. It could work if it were a drop-in replacement of clang-format, but that seems to be very much wishful thinking to me.
First, maintenance burden to verify that the two don't diverge somehow. Secondly, the drop-in replacement wouldn't be possible without changing clang-format itself (e.g. to ignore style options that are for "clang-format++" only). Also, it might divide the users into clang-format camp and clang-format++ camp (which may or may not be a problem).
Lastly, I do think that clang-format can be as reliable with this patch as it's now. Breaking code is of course possible but that's the case of many style options. And these are bugs that will eventually get fixed. It's of course important that this option doesn't break anything ever by default, but given that the default is Leave, and it's implemented as an additional pass, that should be the case.
Also, I'd be a bit surprised if people used it in CI immediately after this feature has landed without verifying that it doesn't break anything on their codebase.
Wed, Jun 30
If we were to start this all over without the need of backward compatibility and the existence of the related unit tests, an enum might be a better option. Then I still think the user might have some trouble relating the following to the enum.If AlwaysOnePerLine: Put each on its own line. Else If AllOnOneLineOrOnePerline: If they all fit on one line: Put all of them on a single line. Else If AllOnNextLine: Put (the rest of) them on the next line. Else: Put each on its own line. Else: ...
Is there anything else in the "Else:" part above? Is there an option that we forgot?
Tue, Jun 29
Formatting part and tests look good to me, but I'd rather see this patch merge all related boolean options into one enum.
Just thinking out loud, but is it doable to merge AllowAllConstructorInitializersOnNextLine, ConstructorInitializerAllOnOneLineOrOnePerLine and this patch's ConstructorInitializerAlwaysOnePerLine into e.g. ConstructorInitializerStyle: AllowNextLine | NonBinPack==AllOnOneLineOrOnePerLine | OnePerLine. And one other enum value for the default case without special handling.
Of course, we'd need to keep that backward compatible.
I can't help with C# part either, unfortunately.
I'll chime in if I see something strange, but current patch looks okay to me. I let other reviewers (@exv) accept it when they feel it's ok.
Jun 16 2021
Jun 9 2021
LGTM. That's a great piece work @feg208. Thank you!
Jun 8 2021
LGTM modulo nits.
Better still how about havingArraryMemberAligmentEnum AlignArrayOfStructures
of "None, Left and Right"
I find boolean options don't stay boolean for long!
Jun 6 2021
This has been superseded by D103245. Closing.
Jun 4 2021
Jun 3 2021
LGTM. Thanks for fixing this!
Do you have commit rights or you need somebody to land it for you?
Jun 2 2021
Thanks for looking into this, but please add a test case that demonstrates the bug to FormatTests.cpp
Also, is there, by any chance, an associated bugzilla ticket?
Thanks for adding the tests. 👍
May 29 2021
LGTM. But please wait for @HazardyKnusperkeks to land.
May 28 2021
Thanks for working on this!
Looks pretty nice, but please clang-format the changes and add some more test cases (cf. inline comment).
Seems really nice. Just some nits & question.
Thanks for resuscitating the other review!
Whoops, We forgot to regenerate ClangFormatStyleOptions.rst here following the change to Format.h
May 19 2021
May 14 2021
Also, please update https://bugs.llvm.org/show_bug.cgi?id=48939 and add it to the description.
LGTM. But please rebase to rerun CI (the commit that provoked the failures has been reverted).
It would be cool if @saugustine could have a look at gdb part though. @ldionne, this patch should unblock adding 32-bit buildbots to CI in D92508.
May 13 2021
LGTM. What do you think, would there be any value in testing different char types?
LGTM. I second what Arthur said.
LGTM. Not blocking, but I'd add foo4 example from the description as a test case (with a link to the bug maybe).
May 12 2021
May 7 2021
May 6 2021
May 5 2021
Oh, I forgot, please add a release note.
LGTM but let's wait a day or two before landing, so that others can chime in.
Btw, do you have commit rights? If no, please provide "Name <email>" for commit attribution.
I like the idea, but we need more tests.
LGTM pending CI.
LGTM pending CI.
You can add a parent revision so that this patch will be applied upon its parent.
Could you please rebase to re-run the CI (that failed for sum unrelated reason)?
May 4 2021
Preferably a new one unless it's something really minor.
According to the wiki, it seems like someone who has commit access must now submit this change.
LGTM. That's great. Thanks for working on this and for the cleanup.
May 3 2021
Looks very good already. Just some questions and test requests.
Is it testable?
- Fix format.
May 1 2021
I went a different way in order to keep backward compatibility.
I renamed Alwayss to OnlyFirstIf and added AllIfsAndElse that behaves as Always in my initial patch.
@MyDeveloperDay, please have another look.
- [clang-format] Apply AllowShortIfStatementsOnASingleLine: AllIfsAndElse to "else if" and "else". Keep backward-compatibility.
Apr 30 2021
LGTM pending CI.
Apr 29 2021
Apr 28 2021