<div dir="ltr">Oh neat, I didn't know about that.  I'll play around with that when I have some time and see how the behavior works with respect to git clang-format (which formats diffs instead of entire files)</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 22, 2016 at 12:29 PM Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Apparently, you can also disable the formatting of a piece of code by<br>
a magic comment. Could be quite useful for those tables. From the<br>
docs:<br>
-----<br>
Clang-format understands also special comments that switch formatting<br>
in a delimited range. The code between a comment // clang-format off<br>
or /* clang-format off */ up to a comment // clang-format on or /*<br>
clang-format on */ will not be formatted. The comments themselves will<br>
be formatted (aligned) normally.<br>
-----<br>
<br>
<br>
On 22 January 2016 at 17:09, Todd Fiala via lldb-dev<br>
<<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> Okay, thanks for the tip!<br>
><br>
> On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>><br>
>> By the way, one place where you are guaranteed to get undesirable results<br>
>> is where you have a large array formatted so that the columns line up.  Like<br>
>> in our options tables in the CommandObjects.  If you're using git, one way<br>
>> to avoid having clang-format touch these files is to commit that file by<br>
>> itself, then run git clang-format (since it only looks at staged files),<br>
>> then git commit --amend.  But of course that will gloss over any other<br>
>> changes you made to the file as well.  But in any case, it's another trick<br>
>> I've found useful occasionally.<br>
>><br>
>> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone <<a href="mailto:katherine_stone@apple.com" target="_blank">katherine_stone@apple.com</a>><br>
>> wrote:<br>
>>><br>
>>> Agreed.  My guidance has been that we go ahead and require submitters to<br>
>>> use clang-format for patches, but to acknowledge that there may be cases<br>
>>> where this produces undesirable results.  Manual formatting to correct these<br>
>>> issues is acceptable and should lead to discussions about concrete examples<br>
>>> where the automated approach is imperfect.<br>
>>><br>
>>> Kate Stone <a href="mailto:k8stone@apple.com" target="_blank">k8stone@apple.com</a><br>
>>>  Xcode Runtime Analysis Tools<br>
>>><br>
>>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev<br>
>>> <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> Okay, sounds like a reasonable thing to try.  We can always review it if<br>
>>> it causes any real issues.<br>
>>><br>
>>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan <<a href="mailto:scallanan@apple.com" target="_blank">scallanan@apple.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> I tend to agree with Zachary on the overall principle – and I would be<br>
>>>>> willing to clang-format functions when I modify them.  I’m concerned about a<br>
>>>>> specific class of functions, though.  Let’s say I have a function that has<br>
>>>>> had lots of activity (I’m thinking of, for example, ParseType off in the<br>
>>>>> DWARF parser).  Unfortunately, such functions tend to be the ones that<br>
>>>>> benefit most from clang-format.<br>
>>>>><br>
>>>>> In such a function, there’s a lot of useful history available via svn<br>
>>>>> blame that helps when fixing bugs.  My concern is that if someone<br>
>>>>> clang-formats this function after applying the kth fix, suddenly I've lost<br>
>>>>> convenient access to that history.  It’s only available with a fair amount<br>
>>>>> of pain, and this pain increases as more fixes are applied because now I<br>
>>>>> need to interleave the info before and after reformatting.<br>
>>>>><br>
>>>>> Would it be reasonable to mark such functions as “Don’t clang-format”?<br>
>>>>> That could be also interpreted as a “// TODO add comments so what this does<br>
>>>>> is more understandable”<br>
>>>><br>
>>>><br>
>>>> Well again by default it's only going to format the code you touch in<br>
>>>> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire<br>
>>>> function is something you would have to explicitly go out of your way to do.<br>
>>>> So it's a judgement call.  If you think the function would be better off<br>
>>>> clang-formatting the entire thing, do that.  If you just want to format the<br>
>>>> lines you're touching because you were in there anyway, that's the default<br>
>>>> behavior.<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> -Todd<br>
>>><br>
>>> _______________________________________________<br>
>>><br>
>>><br>
>>> lldb-dev mailing list<br>
>>> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> -Todd<br>
><br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
><br>
</blockquote></div>