rupprecht marked 3 inline comments as done.
rupprecht 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 = [
----------------
labath wrote:
> 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...
Figured out what was going on and mailed D70324 to prevent this from happening 
to the next person this bites -- which could be me :)

I originally had:

```
self.child.send("help command\n")
self.child.expect_exact("Syntax: command")
```

And based on your suggestion, changed it to:
```
self.expect("help command\n", substrs=["Syntax: command"])
```

Which is wrong, because `self.expect()` calls `self.child.sendline(cmd)`, so 
it's running `"help command\n\n"` == `"help command\nhelp command\n"`.
The `expect_prompt()` helper will match the first prompt it sees, so the second 
run of the command is still in the match buffer. Checking for "Syntax: command" 
would still pass even though it was not intentionally ran twice.

I also tried changing `expect_prompt()` to continuously match until the last 
prompt it sees, but it's simpler to just disallow `\n` in the command.


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

Reply via email to