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

[Todd Fiala via lldb-dev]

I just tried the 'git clang-format' workflow on a gtest change I'll be
committing soon.  It worked just fine and is quite handy.

On Fri, Jan 22, 2016 at 1:13 PM, Sean Callanan <scallanan at apple.com> wrote:

> 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
>
>


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