Doesn’t mean it’s a good or bad pattern, just that “only 1 file will use it” is already false, because we can make lldb use it as a followup and that will get many more.<br><br>I did think about alternative solutions, If this CL wasn’t here, the alternatives i came up would be to either not write this test, or spend several days/weeks writing a tool whose only purpose was to make it possible to write this test.<br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 6, 2018 at 1:32 PM Nico Weber via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">thakis added a comment.<br>
<br>
> We may call these "unit" tests, but they're really gtests, and developers everywhere use gtest for more than just unit tests. We already have tests that create temp files. I don't see why reaching back into the source directory for inputs is too heavyweight for us.<br>
<br>
That's definitely true at Google because it's the only hammer we have there. In LLVM land, we have lit, and gtests really tend to be unit tests there.<br>
<br>
> Also there’s not really that many of these files, and they’re very small.<br>
>  Making it opt-in seems more troue than it’s worth because there’s not going<br>
>  to be a measurable impact of writing the files.<br>
<br>
It's one per test binary, so about 60. I agree that writing 60 files won't have a big time cost, but writing 60 files because a single gtest wants to access a file in the source tree seems questionable to me.<br>
<br>
Furthermore, it's not a move that has good follow-up moves:<br>
<br>
- If this doesn't get widely adopted (as he commit message hopes: "and we just encourage people to use this sparingly") then we have this weird magical setup that's used by one file.<br>
<br>
- If it does get widely adopted, then now we have lots of tests reading stuff from the disk, where writing a binary running under lit would almost certainly lead to a better long term design.<br>
<br>
So I'd encourage you to think about the question "if this CL here wasn't a possible approach, how could I still do what I want?" and do that instead.<br>
<br>
> Fwiw this pattern is also prevalent in lldb with minidump tests.<br>
<br>
I'm not sure if "lldb has it, so it's a good pattern" is necessarily a good argument.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D51561" rel="noreferrer" target="_blank">https://reviews.llvm.org/D51561</a><br>
<br>
<br>
<br>
</blockquote></div>