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

[Sean Callanan via lldb-dev]

Wow, that’s a super handy feature and probably goes a long way toward alleviating concerns about tables.
I have to say, I always feel good vibes about a source base when they have lint directives in comments.  Shows they run lint as a matter of course.

Sean
 
> On Jan 22, 2016, at 12:29 PM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Apparently, you can also disable the formatting of a piece of code by
> a magic comment. Could be quite useful for those tables. From the
> docs:
> -----
> Clang-format understands also special comments that switch formatting
> in a delimited range. The code between a comment // clang-format off
> or /* clang-format off */ up to a comment // clang-format on or /*
> clang-format on */ will not be formatted. The comments themselves will
> be formatted (aligned) normally.
> -----
> 
> 
> On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>> 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 kth 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
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev