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

[Zachary Turner via lldb-dev]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160122/76733caa/attachment.html>