[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion

[Zachary Turner via lldb-commits]

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
On Wed, Feb 7, 2018 at 5:48 PM Zachary Turner <zturner at google.com> wrote:

> 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.
>
> 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.
>
> 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
>
> On Wed, Feb 7, 2018 at 5:29 PM Jim Ingham via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> jingham requested changes to this revision.
>> jingham added a comment.
>> This revision now requires changes to proceed.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> An additional test in the Python testsuite is:
>>
>>   def test_target_create_dash_co(self):
>>       """Test that 'target create --co' completes to 'target variable
>> --core '."""
>>       self.complete_from_to('target create --co', 'target create --core ')
>>
>> So I still don't see why the file check method is preferable.  But to
>> each his own, I guess.
>>
>>
>> https://reviews.llvm.org/D43048
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180208/b259b5e1/attachment-0001.html>