labath added inline comments.
================
Comment at: lldb/packages/Python/lldbsuite/test/terminal/TestEditline.py:37-38
+
+ # Run help for different commands for escape variants to make sure each
+ # one matches uniquely (the buffer isn't cleared in between matches).
+ cases = [
----------------
rupprecht wrote:
> labath wrote:
> > The buffer isn't exactly "cleared", but each "expect" command should only
> > match from the end of the previous match, so repeating the same command
> > should not be a problem. What the other (few) pexpect tests do is put an
> > `self.expect_prompt()` to ensure all output from the previous command is
> > ignored, and lldb is ready to receive a new command. You could do that too.
> > In fact, you could probably use the helper "expect" command which does all
> > of this for you:
> > `self.expect("el ommand{L}c{L}{L}h{R}p".format(...), substrs=["Syntax:
> > command"])`
> The expect helper is nice, thanks!
>
> > but each "expect" command should only match from the end of the previous
> > match
> I am not able to reproduce that. If I change the expect to the static string
> `"Syntax: print"` (not `% cmd`), then the second case (which types `"help
> step"`) passes. Which implies it's checking the entire buffer.
>
> The third case (`"help exit"`) fails because the buffer does not contain the
> `print` help text anymore. But that means this behavior is dependent on the
> relation between help text length and buffer size. For now, I'll leave this
> as separate help commands.
That's very odd. It's definitely not how things behave on my end (the second
check fails straight away), and it's not clear to me why would that differ for
you. Looking at the code, it's pretty obvious
<https://github.com/llvm/llvm-project/blob/b5f14326b447e5a97b3d7654448c36d7745a6882/lldb/third_party/Python/module/pexpect-4.6/pexpect/expect.py#L32>
that pexpect intends to reset the internal buffer to include only the text
after the last match.
I'd like to get to the bottom of this. Can you dig around (maybe step through
the pexpect code) to see what's happening in your case? One thing that's been
causing confusion in the past was the leftover
`third_party/Python/module/pexpect-2.X` folder from the time before we updated
pexpect. However, I find it unlikely that this would be the case here, as this
should have been the pexpect behavior since forever...
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70137/new/
https://reviews.llvm.org/D70137
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
