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

[Zachary Turner via lldb-dev]

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)

On Fri, Jan 22, 2016 at 12:29 PM Pavel Labath <labath at google.com> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160122/391d361a/attachment.html>