[lldb-dev] clang-format now supports return type on separate line

[Todd Fiala via lldb-dev]

Okay, thanks for the tip!

On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner <zturner at google.com> wrote:

> By the way, one place where you are guaranteed to get undesirable results
> is where you have a large array formatted so that the columns line up.
> Like in our options tables in the CommandObjects.  If you're using git, one
> way to avoid having clang-format touch these files is to commit that file
> by itself, then run git clang-format (since it only looks at staged files),
> then git commit --amend.  But of course that will gloss over any other
> changes you made to the file as well.  But in any case, it's another trick
> I've found useful occasionally.
>
> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone <katherine_stone at apple.com>
> wrote:
>
>> Agreed.  My guidance has been that we go ahead and require submitters to
>> use clang-format for patches, but to acknowledge that there may be cases
>> where this produces undesirable results.  Manual formatting to correct
>> these issues is acceptable and should lead to discussions about concrete
>> examples where the automated approach is imperfect.
>>
>> Kate Stone k8stone at apple.com
>>  Xcode Runtime Analysis Tools
>>
>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>
>> Okay, sounds like a reasonable thing to try.  We can always review it if
>> it causes any real issues.
>>
>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan <scallanan at apple.com>
>>> wrote:
>>>
>>>> I tend to agree with Zachary on the overall principle – and I would be
>>>> willing to clang-format functions when I modify them.  I’m concerned about
>>>> a specific class of functions, though.  Let’s say I have a function that
>>>> has had lots of activity (I’m thinking of, for example, ParseType off in
>>>> the DWARF parser).  Unfortunately, such functions tend to be the ones that
>>>> benefit most from clang-format.
>>>>
>>>> In such a function, there’s a lot of useful history available via svn
>>>> blame that helps when fixing bugs.  My concern is that if someone
>>>> clang-formats this function after applying the *k*th fix, suddenly
>>>> I've lost convenient access to that history.  It’s only available with a
>>>> fair amount of pain, and this pain increases as more fixes are applied
>>>> because now I need to interleave the info before and after reformatting.
>>>>
>>>> Would it be reasonable to mark such functions as “Don’t clang-format”?
>>>> That could be also interpreted as a “// TODO add comments so what this does
>>>> is more understandable”
>>>>
>>>
>>> Well again by default it's only going to format the code you touch in
>>> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
>>> function is something you would have to explicitly go out of your way to
>>> do.  So it's a judgement call.  If you think the function would be better
>>> off clang-formatting the entire thing, do that.  If you just want to format
>>> the lines you're touching because you were in there anyway, that's the
>>> default behavior.
>>>
>>
>>
>>
>> --
>> -Todd
>>
>> _______________________________________________
>>
>>
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>


-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160122/fe6a95e1/attachment-0001.html>