- User Since
- Oct 1 2019, 1:21 PM (15 w, 3 d)
Tue, Jan 7
Mon, Jan 6
Fri, Dec 20
Dec 18 2019
This feature is missing unit tests. Also, what is the reason for all the comment changes? I don't think the changed comment lines originally exceeded 80 characters.
Dec 3 2019
Nov 20 2019
Nov 19 2019
Reopening in order to correct the accidentally swapped commits between this ticket and https://reviews.llvm.org/D70165.
Reopening in order to correct the accidentally swapped commits between this ticket and https://reviews.llvm.org/D69238.
Oops, it looks like I mixed up this ticket with https://reviews.llvm.org/D69238. Sorry about that. Would you like me to revert both commits and then re-commit with the correct links, etc.?
Nov 18 2019
Yes, there was a failing unit test that had to be fixed. I reverted the first commit and then committed a version that fixed the failing test.
Nov 15 2019
Nov 14 2019
Nov 8 2019
Nov 6 2019
Oct 31 2019
Never mind, I got it resolved and pushed. Sorry for the noise.
Thanks. Would you mind committing this on my behalf? It seems I wasn't migrated from SVN access to git access. It may take some time to sort out.
Oct 30 2019
Oct 29 2019
Sounds like you know what you're doing.
Oct 25 2019
Oct 17 2019
Oct 15 2019
Oct 9 2019
To me, whether or not the assertion was valid is irrelevant. That assertion was intentionally added, and its replacement with an if() statement materially changes the inputs and outputs of the function. I'm questioning whether the input of a "while" token within a preprocessor statement should output true or false. (Before, it didn't output anything; it errored.) Does this make sense? I'm just asking for clarification on this change.
Oct 7 2019
I don't care for the command line switches that try to emulate compiler flags. I am also of the opinion that external scripts should be used for this functionality. git for Windows gives you a full set of bash utilities to utilize, so doing stuff like this on Windows is much easier now.
I agree with @djasper that this is outside the scope of clang-format. git for Windows gives you a full set of bash utilities to utilize, so doing stuff like this on Windows is much easier now.
I agree that a system in place that either enforces clang-formatting on commit or after the fact would be ideal. Otherwise, I don't see a need to have to approve these NFC commits.
Oct 4 2019
Thanks, please commit on my behalf.
This needs to be more thought out. At the very least it needs to cover more keywords like do, switch, try, and catch. There may be more. Consideration also needs to be made for class, functions, namespace, etc. Otherwise this is an experimental feature at best. There is also confusion with how it may interact with SpaceBeforeCpp11BracedList. The name SpacesAroundBraces is just too generic in that regard considering the fact that braces play multiple roles in C++.
Fixed empty parentheses unit test for C++11 braced initializer list.
You are correct. I'll work on this.
Oct 3 2019
Thanks. Please commit on my behalf when you have a chance.
If you want spaces in your C++11 initializers and nothing else, then you don't want the Cpp11BracedListStyle setting enabled. Turning it off gives you spaces inside without affecting anything else.
Added additional unit tests to verify that the SpaceInEmptyParentheses setting is also correctly adhered to.
I don't think that's a good idea, considering the fact that braces can mean different things in different contexts, and it would cause trouble for existing clang-format settings.
Rebased against master, and also added test case for 'do' statements.
Oct 2 2019
Renamed "OnlyMultiLine" option to "MultiLine", per reviewer request.
@MyDeveloperDay I am not wedded to "OnlyMultiLine". I picked it, as it seemed reasonable to me, but if you think another string expresses the intent better, then feel free to use it.
Thanks for the review. I have added documentation updates.