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
