[Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Jim Ingham via lldb-commits]

If the internal thing is three things in a list, you get back thing one, thing two and thing three in declarative ways rather than "I got three space separated things, maybe they had spaces in them, maybe there were quotes, etc, and don't ever change this now or you'll have to go fix all the tests...  I really don't see how going back to irregular text output grubbing is a step forward.

Also, the SBInternal API's would be much simpler to write, (a) since you wouldn't have to concern yourself with how the other end was going to parse up what you were outputting and (b) because individual API calls are much easier to write than LLDB commands/sub-commands.

You could have your special lldb command that produced JSON and then the test engine had some language to pick fields out, then you could only read this output with confidence, and you're back to the same fragility when testing the results of regular commands.  You could change all the regular commands to optionally produce some structured output, but that's a lot of work to reproduce something that already works pretty well.

Jim



> On Sep 14, 2016, at 4:43 PM, Zachary Turner <zturner at google.com> wrote:
> 
> 
> 
> On Wed, Sep 14, 2016 at 4:39 PM Jim Ingham <jingham at apple.com> wrote:
> 
> > 4. You can test a LOT more things when you are able to use an api that doesn't have to be stable.
> 
> When I mentioned that API, I had in mind an internal Python module that you could use to grub into internals.  I'm all for that.  I'm not so much in favor of "I have an ad hoc command that prints out various bits of texts, and we'll use that for testing."
> 
> Is it any different though? Take the API you're imagining to grub for internals.  Now imagine the EXACT same API as an lldb command.  What's the difference?  What could you do with the Python API that you couldn't do with the command API?  Aside from write imperative control flow constructs, which I see as a positive rather than a negative.