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