<div dir="ltr">Ok, that makes sense. I don't see this as a good enough argument to remove backslash support though.<div><br></div><div><div>For problems like the clang_cc1 substitution mistakes, it would be much better to just improve the substitution support so that those cause immediate test failures. I would definitely support a move to make lit's substitution machinery more strict. For problems like your first search, I can appreciate how wrapped lines make this less trivial, but this isn't enough of a use case to motivate removing the feature in my opinion.</div>
<div><div><br></div><div>My opinion can be summarized as:</div><div><br></div><div>1. If you are worried about bogus or broken tests, but you have an automatic way to detect the brokenness, then the right way to attack this is to build the check into the test runner so no one ever can write the test to pass again.</div>
<div><br></div><div>2. If you are trying to do more fuzzy searches that are going to no be fully automatic, the individual developer can deal with the existence of wrapped lines. Or we could add a way to have lit run a regexp over all of the (collapsed) test script lines if this is a really important use case for you. Either way, its not a good enough argument to remove a useful feature.</div>
<div><br></div><div> - Daniel</div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 8, 2013 at 11:47 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <br>
    <div>On 08/12/2013 16:43, Daniel Dunbar
      wrote:<br>
    </div>
    <blockquote type="cite">
      <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">With

        one-to-one mapping, it becomes possible to use simple tools like
        grep to validate common mistakes like %clang / %clang_cc1
        mixups, a missing -o flag and so on.<br>
        <br>
        Right now there's no obvious way to do those checks and we've
        ended up without an easy way to lint for broken tests as a
        result. Each broken test has a high cost so we need to
        continually look at ways to improve the situation.</blockquote>
      <div><br>
      </div>
      <div>Can you elaborate on exactly what kind of checks you want to
        do?</div>
    </blockquote>
    <br></div>
    Basically, it's for asking questions about what's currently tested..<br>
    <br>
    <blockquote>e.g. <i>Find me all tests for c++11 exceptions</i>:<br>
      <br>
      <code>git grep 'RUN:.*c++11' -- test/ | grep exceptions</code><br>
    </blockquote>
    <br>
    .. experimenting with new features or refactoring existing tests..<br>
    <br>
    <blockquote>e.g. <i>How many tests could we add -fsyntax-only to?</i><br>
      <br>
      <code>giteach perl -pi -e 's/((RUN:.*%clang_cc1)(.*))$/$2
        -fsyntax-only$3/g unless
m/(-fsyntax-only|-analyze|-arcmt-check|-arcmt-migrate|-o|-emit-llvm|-E|-ast-print|-ast-dump|[|>]|\\$)/'</code><br>
      <br>
      Answer, 405. Then git diff and page through to see if any are
      actionable.<br>
    </blockquote>
    <br>
    and fixing broken tests..<br>
    <br>
    <blockquote>eg. <i>Let's find and fix %clang_cc1 substitution
        mistakes..</i><br>
      <br>
      giteach perl -pi -e 's/(RUN:.*%clang_cc1)[^\s]+/$1/g'<br>
    </blockquote>
    <br>
    I committed the results of this run just a few minutes ago in
    r196729 and r196730.<br>
    <br>
    One was a test that had been disabled since 2007.<br>
    <br>
    Losing 80 columns is a small price to pay if it'll help make tests
    easier to write, understand and validate in my opinion.<br>
    <br>
    (The two editors I use, vim and XCode, both do a good job of virtual
    line wrapping so it turns out long RUN lines aren't that much of a
    big deal in practice. But I can see why it may be a bigger problem
    with editors that don't support wrapping. Is this still a problem in
    2013?)<div class="im"><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>
  </div></div>

</blockquote></div><br></div>