Oct 18 2017
Oct 13 2017
Oct 12 2017
I believe that this extra option is not worth its cost in terms of maintainability and (more importantly) discoverability of options. You say that the behavior is documented in your coding style, but it is not (probably for the same reason). There isn't even a single example of this, I think. As such, I don't think we should go forward with adding this option.
Oct 11 2017
Oct 1 2017
Sep 30 2017
Sep 28 2017
Sep 26 2017
Sep 21 2017
Sep 19 2017
I think doing the computation twice is fine. Or at least, I'd need a test case where it actually shows substantial overhead before doing what you are doing here. Understand that creating more States and making the State object itself larger also has cost and that cost occurs in the combinatorial exploration of the solution space. Doing an additional computation at the end should be comparatively cheap. Look at it this way: During the exploration of the solution space, we might enter breakProtrudingToken many times for the same comment. One more time during reconstruction of the solution is not that harmful.
Sep 18 2017
Sep 14 2017
I still don't understand yet. breakProtrudingToken has basically two options:
Sep 12 2017
I'd still prefer individual patches for each of these changes. If the code review system or VCS make it hard for you to deal with two adjacent changes this way, do them in sequence.
BraceWrapping.AfterExternC makes sense to me.
I have a slightly hard time grasping what this patch now actually does? Doesn't it simply try to decide whether or not to make a split locally be comparing the PenaltyBreakComment against the penalty for the access characters? If so, couldn't we simply do that as an implementation detail of breakProtrudingToken() without needing to let anything outside of it now and without introducing State.Reflow?
I am very strongly against a flag that just leaves the line break as is. What's the motivation?
Sep 11 2017
Sep 7 2017
Submitted as r312721. Thank you.
Looks good. Sorry for the delay.
Also run dump_format_style.py and keep the changed .rst file in this change.
This change needs to be made to include/clang/Format/Format.h and then the rst file needs to be regenerated with docs/tools/dump_format_style.py.
Sep 6 2017
Note that these changes need to be made to the corresponding comments in include/clang/Format/Format.h and then this file is auto-generated with docs/tools/dump_format_style.py.
Sep 5 2017
Sep 4 2017
Sep 3 2017
Sep 1 2017
Aug 31 2017
Aug 30 2017
Aug 29 2017
Just a few minor comments, otherwise looks good.
Are you changing the line endings here? Phabricator tells me that basically all the lines change. If so, please don't ;).
Looks good. Thank you.
Aug 28 2017
Yay for *removing* complexity for a change :).
Let me know how it goes in practice.
Aug 27 2017
Aug 25 2017
Aug 24 2017
From my side this looks good for now (we can always improve more later). Krasimir, what do you think?
Does the test still test the same thing if you set the column limit to 60 and remove 20 spaces? If not, this is fine.
Aug 23 2017
Aug 22 2017
Krasimir: Can you actually give this a round of review? I will also try to do so tomorrow.
If no tests break with this, lets just go for it. We can follow up and fix individual cases if we find undesired behavior.
Aug 21 2017
Aug 16 2017
Aug 14 2017
Aug 10 2017
Aug 9 2017
Looks good. Thank you!
Aug 8 2017
Manuel: Can you take a look at the last comment here? Why does PPBranchLevel start at -1?
Aug 6 2017