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 <scalla...@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@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@lists.llvm.org> wrote: > >> Okay, thanks for the tip! > >> > >> On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner <ztur...@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_st...@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 k8st...@apple.com > >>>> Xcode Runtime Analysis Tools > >>>> > >>>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev > >>>> <lldb-dev@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 <ztur...@google.com> > >>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan <scalla...@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@lists.llvm.org > >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> > >> > >> > >> > >> -- > >> -Todd > >> > >> _______________________________________________ > >> lldb-dev mailing list > >> lldb-dev@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev