<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.<br><br><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span style="background-color: rgba(255, 255, 255, 0);"><font>Kate Stone</font> <font><a href="mailto:k8stone@apple.com">k8stone@apple.com</a></font></span></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span style="background-color: rgba(255, 255, 255, 0);"><font></font> Xcode Runtime Analysis Tools</span></div></div><div><br>On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Okay, sounds like a reasonable thing to try.  We can always review it if it causes any real issues.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan <<a href="mailto:scallanan@apple.com" target="_blank">scallanan@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<br><div><br></div><div>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 <i>k</i>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.</div><div><br></div><div>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”</div></div></blockquote><div><br></div></span><div>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. </div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>lldb-dev mailing list</span><br><span><a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a></span><br><span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a></span><br></div></blockquote></body></html>