<div dir="ltr">Okay, thanks for the tip!</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 8:32 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">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.</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 22, 2016 at 7:09 AM Kate Stone <<a href="mailto:katherine_stone@apple.com" target="_blank">katherine_stone@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 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"><span style="background-color:rgba(255,255,255,0)"><font>Kate Stone</font> <font><a href="mailto:k8stone@apple.com" target="_blank">k8stone@apple.com</a></font></span></div><div style="word-wrap:break-word"><span style="background-color:rgba(255,255,255,0)"><font></font> Xcode Runtime Analysis Tools</span></div></div></div><div dir="auto"><div><br>On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">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><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><div dir="ltr">-Todd</div></div>
</div>
</div></blockquote></div><div dir="auto"><blockquote type="cite"><div><span>_______________________________________________</span></div></blockquote></div><div dir="auto"><blockquote type="cite"><div><br><span>lldb-dev mailing list</span><br><span><a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a></span><br><span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a></span><br></div></blockquote></div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>