<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 3:19 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17 March 2016 at 15:11, David Blaikie via llvm-commits<br>
<span class=""><<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> Yeah, if we're going to get into the business of making bitcode robust to<br>
> arbitrary errors, we really should talk about a testing strategy for it. I<br>
> imagine that'll probably look like a fuzzer (as mentioned in review) and<br>
> we'll just pull out cases from the fuzzer to check in as test cases & keep<br>
> as part of the fuzzer's seed library (whatever the right word is for that).<br>
<br>
</span>I don't think a fuzzer is sufficient.<br></blockquote><div><br></div><div>A fuzzer's the only way we're likely to find all the cases - but, yes, once we identify and fix a case, we would move teh minimal/reduced fuzzer case into a corpus in our regression test suite (most fuzzing cases are pretty small - the big ones, well we tend not to checkin big tests for non-fuzzy issues these days already, so I think we'd just live with those gaps or put them in the test-suite proper) alongside all our usual regression tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In any other area I can refactor code and have a pretty good<br>
confidence with just check-all that I at least haven't regressed<br>
anything.<br>
<br>
If we don't add checks for broken files, refactoring to, for example,<br>
use TypedError will not be as easy.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>