So what's your take on this particular case? As far as I can see (please correct me if I'm wrong), the LIT-only tests:
1. Don't cover the case where a function is split into disjoint regions, right? 2. Also don't cover the cross-targeting case (ex. the native PDB reader hosted on Linux) 3. A bug in LLD might inadvertently make the tests pass w/o testing what they are supposed to (let's say that it incorrectly ingores the hardcoded order and lays everything contiguously) On Fri, Jun 8, 2018 at 10:14 AM, Zachary Turner <ztur...@google.com> wrote: > On Fri, Jun 8, 2018 at 10:10 AM Leonard Mosescu <mose...@google.com> > wrote: > >> I agree, checked in binaries are not always pretty. But some coverage >> depends checked in binaries (or at very least is dramatically harder to get >> the same thing from source) >> >> Are we saying that sacrificing coverage to keep tests smaller should be >> the default trade off? >> > > It's probably worth evaluating on a case by case basis. Often time there > are ways to use lower level LLVM tools like llvm-mc, yaml2obj, etc so that > we can construct binaries on the fly which are reproducible. In these > cases we should check in the "meta-inputs" that allow us to reproducibly > construct the test inputs on the fly. > > One can easily imagine the repository growing to many tens of gigabytes > just due to test inputs, which is not really scalable. >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
