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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
