[PATCH] D80694: Improve lit.py's usability by highlighting failing lines.

[Varun Gandhi via Phabricator via llvm-commits]

varungandhi-apple added a comment.

@JDevlieghere, that is part of the code that is writing out the command line.

  # TestRunner.py
  def executeScriptInternal(test, litConfig, tmpBase, commands, cwd):
      # ... skipped
      for i,result in enumerate(results):
          # Write the command line run.
          out += '$ %s\n' % (' '.join('"%s"' % s
                                      for s in result.command.args),)

The commit which added it has the following message:

  commit 591838d1d33bc0dc5d2ffc66dd22176f280cc625
  Author: Daniel Dunbar <daniel at zuster.org>
  Date:   Thu Jun 2 23:49:42 2016 +0000
  
      [lit] Improve readability of failing scripts.
  
       - This only applies to scripts executed by the _internal_ shell script
         interpreter.
  
       - This patch reworks the log to look more like a shell transcript, and be less
         verbose (but in the interest of calling attention to the important parts).
  
      Here is an example of the new format, for commands with/without failures and
      with/without output:
  
      $ true
      $ echo hi
      hi
  
      $ false
      note: command had no output on stdout or stderr
      error: command failed with exit status 1

While the commit message makes it seem like the double-quotes
should not be present, the commit does add tests with double-quotes,
so I'm guessing it is intentional and not accidental. I'm guessing the
answer to your question is probably the "but in the interest of calling
attention to the important parts", which involves specifying each arg.



================
Comment at: llvm/utils/lit/lit/TestRunner.py:1637-1639
+    output = createScriptOutput(litConfig, script,
+                                out if out else err,
+                                status, exitCode)
----------------
The `out if out else err` might seem a bit strange (this was tripping me up for a while). For reasons I haven't tried digging into (perhaps it has to do with internal vs external shell), looks like sometimes the command output that's applicable is coming from stdout and sometimes it is coming from stderr. You can look at the `shtest-run-at-line.py` test case to see this in action. So I ended up going with a best effort "try this or that". Maybe we can make this more precise.

[Now I'm wondering if this ^ should be a TODO in the code instead of a review comment...]


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80694/new/

https://reviews.llvm.org/D80694