<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 8, 2013 at 1:57 AM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div class="im">On Thu, Nov 7, 2013 at 10:48 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Fri, Nov 8, 2013 at 12:49 AM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Daniel,<br>
<br>
Here's a good one for you..<br>
<br>
I've recently been fixing a whole lot of lit tests in the LLVM /
clang suites that don't check anything.<br>
<br>
It was a mystery why people keep checking in tests like this:<br>
<br>
<code>// RUN: clang-check "%s" -- -target x86_64-apple-darwin10
-fasm-blocks 2>&1 |</code><code><br>
</code><code>// </code><code>FileCheck %s</code><br>
<br>
The first line will run successfully, and the second doesn't begin
with RUN so the test passes silently. Not good.<br>
<br>
Then it dawned on me -- contributors must be running clang-format
before committing, causing their RUN lines to get split up at the
line boundary.<br>
<br>
I know this isn't strictly a clang-format bug, but it's time
consuming to manually audit and find no-op tests like this after the
fact and the failure mode is insidious because these tests will
always silently pass.<br></div></blockquote><div><br></div></div><div>Although it doesn't eliminate the hassle of having to manually fix this, it seems like at least one issue worth fixing in its own right is the fact that RUN lines ending with a | are silently accepted by our test infrastructure.</div>
<div><br></div><div>Also, FWIW, it seems like clang-format's comment reflowing turns out to do the wrong thing in a ton of (most?) scenarios (for example, it will wrap the last word onto the next line, leaving a bunch of spurious "one word" lines), to the point that I wish there were an option to tell clang-format to not mess with comments at all.</div>
</div></div></div></blockquote><div><br></div></div><div>clang-format does not "reflow" yet. It just breaks a comment if it is too long. We'll likely want a "reflow" option, but probably bound to a specific "editor mode", so that clang-format does not mess up some person's ASCII-art comment unless it is done in an editor and the result can easily be undone.</div>
</div></div></div></blockquote><div><br></div><div>Ok, that explains it. I guess I was misinterpreting "reflow not implemented" as "broken".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>FWIW, I consider a "spurious on word" comment better than a comment violating the column limit, so I am quite strongly against just turning comment breaking off.</div></div></div></div></blockquote>
<div><br></div><div>Maybe better, but still unacceptable (it's a tough pickle to get out of). This is a not-that-extreme example of what I have seen (on some random lorem ipsum text):</div><div><br></div><div><div>// Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas mattis quam</div>
<div>// non nibh</div><div>// pretium ultrices. Etiam iaculis facilisis tristique. Suspendisse at mattis</div><div>// magna.</div><div>// Fusce facilisis purus dui, eget porttitor velit porta at. Nulla commodo</div><div>
// mauris</div><div>// porttitor mauris malesuada, quis facilisis justo egestas. Cras laoreet neque</div><div>// est, vel</div><div>// congue nisi dapibus mollis. Morbi vehicula auctor libero, sit amet</div><div>// pellentesque justo.</div>
<div>// Mauris nisi nisi, sodales id ligula in, mattis sollicitudin lorem. Sed</div><div>// eleifend dui</div><div>// sit amet arcu vehicula dignissim. Suspendisse at porta felis, ut interdum</div><div>// nisl. Donec</div>
<div>// pellentesque justo ac dui sagittis, et facilisis augue fermentum. Fusce</div><div>// dapibus</div><div>// pulvinar erat et blandit. Praesent in quam non nunc consequat venenatis ac</div><div>// sed ipsum.</div><div>
// Morbi rutrum leo quis elit iaculis tristique. Curabitur et metus justo.</div></div><div><br></div><div>This kind of comment shape would not be acceptable in any codebase I know of. I think it could be argued that simply not touching comments is the better choice, but since it seems like proper reflowing is on the agenda, it's probably not worth discussing (especially since it's so easy to fix with `gq` in vim).</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div bgcolor="#FFFFFF" text="#000000">
<br>
I was wondering if you can think of a way to exclude the test suites
from clang-format and clang-format-diff runs. Guessing this could be
tricky given that there are several different ways to run
clang-format but something needs to be done..<span><font color="#888888"><br>
<br>
Alp.<br>
<br>
<pre cols="72">--
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a>
the browser experts
</pre>
</font></span></div>
<br></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>