Also, failures that are easy to reproduce are easy to debug.  When a test fails this way, you get a command line that can reproduce the problem that can be debugged directly without having to debug across the python boundary.  I find that very helpful personally <br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 7, 2018 at 5:48 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Same reason that people use perl for heavy text processing, R for scientific programming, python for rapid iteration.  It’s what they’re built for.  When something is built for a very focused specific problem domain, the problems in that domain can be expressed very concisely and naturally.</div><div dir="auto"><br></div><div dir="auto">In the current python test there’s 4-6 lines of Python boilerplate for every 2-3 lines of test “meat”.  And it’s all code, making matters even worse.</div><div dir="auto"><br></div><div dir="auto">A FileCheck test will have approximately 0 lines of text that aren’t part of the “meat” of the test, and on top of that it can poke at every low level detail of a system, not just those that are blessed with an api</div><div><br><div class="gmail_quote"><div>On Wed, Feb 7, 2018 at 5:29 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">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">jingham requested changes to this revision.<br>
jingham added a comment.<br>
This revision now requires changes to proceed.<br>
<br>
You do care about the common match string.  When the lldb driver handles completion, if the common match string is not null, we append that to the line at the cursor position, then present the matches if there is more than one.  So the common match string also has to be tested.<br>
<br>
The ability to page the completion requests in the API would be useful for instance in symbol completion where you can get lots of matches, but if you only plan to display the first page you'd rather not pay the cost to go find them all.  I put that in the SB API's because I didn't want to have to add another one when I got around to implementing this.  When I get around to this I'll fix the docs...  But you could remove that from the lldb private version if you're so motivated.  I'll still remember I intended to extend it this way, even if nobody else will see that.<br>
<br>
We can't return a std::pair across the SB API's, but we could make the common match be another parameter.  There was some reason this seemed logical to me at the time, but I must admit I can't remember why now.  It is in practice easy to use, however.  You append element 0 to the cursor position, then print the rest of the completions if num_matches is > 1.  Again, feel free to switch the lldb_private API if it bugs you.<br>
<br>
An additional test in the Python testsuite is:<br>
<br>
  def test_target_create_dash_co(self):<br>
      """Test that 'target create --co' completes to 'target variable --core '."""<br>
      self.complete_from_to('target create --co', 'target create --core ')<br>
<br>
So I still don't see why the file check method is preferable.  But to each his own, I guess.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D43048" rel="noreferrer" target="_blank">https://reviews.llvm.org/D43048</a><br>
<br>
<br>
<br>
</blockquote></div></div></blockquote></div>