davide abandoned this revision.
davide added a comment.
Cleaning up my queue.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D43048/new/
https://reviews.llvm.org/D43048
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.l
First, I want to apologise for derailing the tab completion review.
However, now that the cat's out of the bag, let me elaborate on what I
meant.
For example, this is how a typical instruction emulation test looks right now:
TEST_F(Testx86AssemblyInspectionEngine, TestSimp
Ah, no. Pavel suggested that the unwind plan unittests should be turned into
FileCheck tests, and then Davide suggested that he'd heard unwind testing is
difficult (he was conflating the unwind sources -> UnwindPlan IR conversions
and the runtime use of UnwindPlans to walk the stack & find spil
Sure I don’t think anyone disputes that, but I thought we were discussing
an ideal end state
On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda wrote:
>
>
> > On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote:
> >
> >
> >
> > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda
> wrote:
> >>
> >>
> >> >
> On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote:
>
>
>
> On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote:
>>
>>
>> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator
>> > wrote:
>> >
>> > zturner added a comment.
>> >
>> > In https://reviews.llvm.org/D43048#1005513,
On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote:
>
>
> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator <
> revi...@reviews.llvm.org> wrote:
> >
> > zturner added a comment.
> >
> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> >
> > I don't think we'd nece
> On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator
> wrote:
>
> zturner added a comment.
>
> In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
>
>> No, the unwind unittests that exist today should stay written as unit tests.
>> These are testing the conversion of
zturner added a comment.
In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote:
> No, the unwind unittests that exist today should stay written as unit tests.
> These are testing the conversion of native unwind formats -- for instance,
> eh_frame, compact unwind, or instruction analy
jasonmolenda added a comment.
No, the unwind unittests that exist today should stay written as unit tests.
These are testing the conversion of native unwind formats -- for instance,
eh_frame, compact unwind, or instruction analysis -- into the intermediate
UnwindPlan representation in lldb. T
davide added a comment.
In https://reviews.llvm.org/D43048#1004807, @labath wrote:
> (Btw, if you're looking for things to FileCheck-ify, I think the stuff under
> `lldb/unittests/UnwindAssembly` is a prime candidate and has a much higher
> bang/buck ratio.)
If you have ideas on how to FileCh
labath added a comment.
(Btw, if you're looking for things to FileCheck-ify, I think the stuff under
`lldb/unittests/UnwindAssembly` is a prime candidate and has a much higher
bang/buck ratio.)
https://reviews.llvm.org/D43048
___
lldb-commits mail
labath added a comment.
The change seems fine to me, and I don't really have anything to add to the
things that were said already.
Testing the completion of things that require a target/module/etc. will be a
bit tricky, but that's something we should figure out anyway to have more
targeted com
On Wed, Feb 7, 2018 at 8:20 PM, Adrian Prantl wrote:
>
>
> > On Feb 7, 2018, at 6:40 PM, Zachary Turner wrote:
>
> > and the command line in the log file doesn’t ever work for me'
>
> That's a bug. Can you show me an example where this breaks for you? I'd
> like to investigate this.
>
> -- adri
> On Feb 7, 2018, at 6:40 PM, Zachary Turner wrote:
> and the command line in the log file doesn’t ever work for me'
That's a bug. Can you show me an example where this breaks for you? I'd like to
investigate this.
-- adrian
___
lldb-commits maili
Yes but debugging across several api calls is annoying, and the command
line in the log file doesn’t ever work for me
On Wed, Feb 7, 2018 at 6:07 PM Jim Ingham via Phabricator <
revi...@reviews.llvm.org> wrote:
> jingham added a comment.
>
> If a dotest test fails, you go to the Failure-whatever.l
jingham added a comment.
If a dotest test fails, you go to the Failure-whatever.log, take the last line,
add a -d to it, and run it. It suspends itself, then you attach to the Python
instance with the debugger.
https://reviews.llvm.org/D43048
___
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
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 c
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
zturner added a comment.
On the issue of keeping the other test, I think when an SB API method is
basically a pass-through to a private method, then having a test of the SB API
method that verifies "did the correct native method get called" is useful if
for no other reason than to verify the co
zturner added a comment.
Number of matches might be sufficient, but it might be nice to know if the
ordering of matches changes for some reason. Unless there's a specific reason
we want to allow an unstable order, enforcing a stable order seems desirable
just on principle.
https://reviews.ll
davide added a comment.
In https://reviews.llvm.org/D43048#1001311, @davide wrote:
> In https://reviews.llvm.org/D43048#1001283, @zturner wrote:
>
> > By the way, I'd suggest printing indices in front of each match and
> > including those in the FileCheck tests. Otherwise we could miss
> > com
davide added a comment.
In https://reviews.llvm.org/D43048#1001283, @zturner wrote:
> By the way, I'd suggest printing indices in front of each match and including
> those in the FileCheck tests. Otherwise we could miss completions that sneak
> in.
Instead, or in addition, we might dump the
davide added a comment.
In https://reviews.llvm.org/D43048#1001293, @davide wrote:
> In https://reviews.llvm.org/D43048#1001287, @jingham wrote:
>
> > The current auto-completer tests aren't interactive - they do exactly the
> > same thing your command does, but from Python. It's fine if you wa
davide added a comment.
In https://reviews.llvm.org/D43048#1001287, @jingham wrote:
> The current auto-completer tests aren't interactive - they do exactly the
> same thing your command does, but from Python. It's fine if you want to add
> tests but please don't remove the current tests since
jingham added a comment.
The current auto-completer tests aren't interactive - they do exactly the same
thing your command does, but from Python. It's fine if you want to add tests
but please don't remove the current tests since they directly test what the SB
clients use.
This will only allow
zturner added a comment.
By the way, I'd suggest printing indices in front of each match and including
those in the FileCheck tests. Otherwise we could miss completions that sneak
in.
https://reviews.llvm.org/D43048
___
lldb-commits mailing list
zturner added a comment.
In the future, we could add options to the `autocomplete` subcommand that would
allow specification of a target, and things like cursor position to maximize
testability.
In general though, I like the approach. It's not hard to imagine 50+ tests
being written just for
davide added a comment.
You can take a look at the
`test/testcases/functionalities/completion/TestCompletion.py` for the python
equivalent. I find the potential FileCheck'ed version much easier to
read/write/understand.
I'm possibly biased having worked many years on LLVM, hence I'm asking for
vsk added a comment.
The general direction lgtm, I'd be happy if we could replace interactive
autocomplete tests with this.
https://reviews.llvm.org/D43048
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
davide created this revision.
davide added reviewers: aprantl, vsk, friss, labath, zturner, jingham,
jasonmolenda.
This is an experiment to improve out lldb testing capabilities and making them
more similar to the one used in LLVM.
Example:
davide@Davidinos-Mac-Pro ~/w/l/b/bin> ./lldb-test a
31 matches
Mail list logo