<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 7, 2017 at 1:20 PM, George Karpenkov via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thus, I propose modifying FileCheck default behavior to dump all swallowed output on stderr when the test has failed.<br>
Would there be any objections to such a change?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand the concern that log files might become unnecessarily large, but since it would only be done for failed<br>
test I think the added readability would be worth it.<br></blockquote><div><br></div><div>I disagree, it would be too much output. During development, it's pretty common to cause tens of tests to fail. I don't really want 10 entire assembly files dumped into my console during incremental development. Our test output is already long, and I wish it were shorter.</div><div><br></div><div>I agree that this is a real problem when remote buildbots in different configurations get involved. Locally debugging FileCheck failures is easy, you just copy-paste the command like you said and pipe it to less. It's only a pain when you aren't sure if a failure on a bot will reproduce locally. So, I would be in favor of an option to lit that we enable on buildslaves that dumps the output. We already have a '\bFileCheck\b' substitution in lit. We'd just expand it to 'FileCheck --dump-on-failure' or something on bots.</div></div></div></div>