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