- User Since
- Apr 25 2017, 12:43 AM (38 w, 1 d)
Dec 18 2017
So you mean a solution like the one discussed earlier would be the way to go?
Dec 6 2017
Ok, that's probably where our different opinions come from - I would want a macro to be formatted to reflect how it's implemented, because otherwise I'm going to be surprised when I look at the implementation, and I consider surprises to be something to avoid in programming in general, where possible.
Dec 5 2017
I don't think this is really relevant for this tool: if someone changes the implementation of the macro, then *they* must indeed if it should not be formatted like a namespace (and keep the clang-format configuration unchanged), or if it should now be formatted like a class (and thus make changes to clang-format configuration). Here we are not defining what the macro does, but how clang-format should indent it : in most case I don't think the indentation format should actually depend on the way it is implemented...
Dec 1 2017
As far as "parsing" and formatting inside the block is concerned, this is indeed unrelated (and would totally work if all macros where specified with some preprocessor definitions).
Indeed, looks good, thanks!
Definitely that would be much more expressive. But this approach is also incomplete: in case of namespace (and possibly others?), we also need to perform the reverse operation, e.g. to "generate" a macro call for rewriting the closing comment.
I think the difference between code and comments is that code "words" are easily 10 characters or more, whereas actual words (in comments) are very often less than 10 characters: so code overflowing by 10 characters is not very frequent. whereas small words in comment will often get closer to the "extra" limit.
Nov 23 2017
In the above example, we add 3 line breaks, and we'd add 1 (or more) additional line breaks when reflowing below the column limit.
I agree that that can lead to different overall outcomes, but I don't see how the approach of this patch really fixes it - it will only ever reflow below the column limit, so it'll also lead to states for long lines where reflowing and leaving chars over the line limit might be the overall best choice (unless I'm missing something)?
Nov 21 2017
Btw, another issue I am having is that reflowing does not respect the alignment. For exemple:
Generally, this indeed improves the situation (though I cannot say much about the code itself, it is still too subtle for my shallow knowledge of clang-format).
Nov 20 2017
Nov 9 2017
Address review comments
Unless I'm missing something, I'd agree with Daniel; this is not a rule that's widely used, and I'd say reformatting a code base to the clang-formatted variant will not regress readability.
Sorry for the long response time. I don't see this style rule expressed explicitly in the Skia or QtCreator style guides - is this something that just happens to be done sometimes in the code bases?
Oct 24 2017
My question is: if CanBreak is false, we currently don't call breakProtrudingToken. So either we do something very wrong in that case (which might be true, but I'd like to understand why) or we should be able to just calculate the penalty by not breaking anything and go on.
Sep 20 2017
This cannot be implemented where we currently call breakProtrudingToken(), since this function starts by 'creating' the BreakableToken and dealing with meany corner cases: so this should be done before in any case.
But the code at the end of breakProtrudingToken() is actually very similar to what you propose.
Sep 19 2017
Remove Reflow from LineState, and perform the decision again during reconstruction phase.
I am still trying to get to the bottom of this assertion, any hint where to look for?
For one thing, we need to update the state to store the "decision" of the reflowing mode, which is performed only in DryRun=true mode, to avoid doing the computation multiple times.
Replace sorted list with hashtable.
Sep 13 2017
Split diff: handle only statements in here, namespace macros will be moved to another one.
Fix review comments, before splitting the commit.
Reorder the functions to minimize diff.
Sep 12 2017
Rebase to master to fix merge issue
Sep 11 2017
Jul 28 2017
Jul 24 2017
Jul 23 2017
Address review commentsx
Address review comments
Jul 18 2017
So, there are two things in this patch: Statement macros and namespace macros. Lets break this out and handle them individually. They really aren't related that much.
Add more tests
Jul 17 2017
Jul 13 2017
Move code out of optimizer, directly into ContinuationIndenter::breakProtrudingToken(), to minimize impact on performance.
Comment reflowing of breakable items which break the limit will be slightly slower, since we now consider the two options; however this change has no impact on the performance of processing non-breakable items, and may actually increase the operformance of processing breakable items which do not need to be reflowed.
Jul 12 2017
I renamed the option to AlignAfterOperator, is it acceptable now?
(I also thought of UnindentOperator, but I think it is better to keep the notion of alignment)
Rename option to AlignAfterOperator
Jul 4 2017
Jun 30 2017
Jun 29 2017
Jun 28 2017
Jun 26 2017
Merge SplitEmptyClass/Struct/Union options into a single SplitEmptyRecord option.
Complete refactor to make the processing much more generic
I don't know if some style would want different styles, and I agree with you on principle; but since the brace wrapping is already configured for each kind of record, I choose to keep things consistent and have flags for each kind of record.
But I can merge the options, and keep only SplitEmptyRecord and SplitEmptyNamespace, if you really think it is better.
Jun 23 2017
Jun 21 2017
Fix according to review comments
Jun 20 2017
Enable merging records for Mozilla style
Rebase & fix indentation when newline is inserted after return or equal.
This style is used in the Skia project.
Jun 19 2017
Fix case where the content fits on a line, by wrapping after each comma, like this: