[lldb][test] Add `pexpect` category for tests that `import pexpect` (#84860)

Instead of directly annotating pexpect-based tests with
`@skipIfWindows`, we can tag them with a new `pexpect` category.

[lldb][test] Add `pexpect` category for tests that `import pexpect` (#84860)

Instead of directly annotating pexpect-based tests with
`@skipIfWindows`, we can tag them with a new `pexpect` category. We
still automatically skip windows behavior by adding `pexpect` to the
skip category list if the platform is windows, but also allow
non-Windows users to skip them by configuring cmake with
`-DLLDB_TEST_USER_ARGS=--skip-category=pexpect`

As a prerequisite, remove the restriction that `@add_test_categories`
can only apply to test cases, and we make the test runner look for
categories on both the class and the test method.

show more ...

[lldb] Fix PExpectTest when using utf-8 as the encoding

PExpect 4.6, when using 'utf-8' throws a TypeError when trying to write
to the log file:

File "llvm-project/lldb/third_party/Python/module/

[lldb] Fix PExpectTest when using utf-8 as the encoding

PExpect 4.6, when using 'utf-8' throws a TypeError when trying to write
to the log file:

File "llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/spawnbase.py", line 126, in _log
self.logfile.write(s)
TypeError: a bytes-like object is required, not 'str'

This looks like a bug in PExpect to me. Since the log file is only used
for tracing, work around the issue by disabling the log file when
specifying an encoding. This should fix the Debian bot [1] which runs
the test with tracing enabled (-t).

[1] https://lab.llvm.org/buildbot/#/builders/68/builds/59955

show more ...

[lldb] Support Unicode in the prompt (#66312)

Account for Unicode when computing the prompt column width. Previously,
the string length (i.e. number of bytes) rather than the width of the
Glyph wa

[lldb] Support Unicode in the prompt (#66312)

Account for Unicode when computing the prompt column width. Previously,
the string length (i.e. number of bytes) rather than the width of the
Glyph was used to compute the cursor position. The result was that the
cursor would be offset to the right when using a prompt containing
Unicode.

show more ...

[lldb] Remove use of __future__ in python

These were useful primarily for the Python 2 to 3 transition. Python 2
is no longer supported so these are no longer necessary.

Differential Revision: http

[lldb] Remove use of __future__ in python

These were useful primarily for the Python 2 to 3 transition. Python 2
is no longer supported so these are no longer necessary.

Differential Revision: https://reviews.llvm.org/D157759

show more ...

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problem

[NFC][Py Reformat] Reformat python files in lldb

This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).

If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.

RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential revision: https://reviews.llvm.org/D151460

show more ...

[lldb] Remove uses of six module (NFC)

With lldb (& llvm) requiring Python 3.6+, use of the `six` module can be removed.

Differential Revision: https://reviews.llvm.org/D131304

[lldb/test] Fix PExpect.launch issue when disabling color support

This patch should fix a bug in PExpect.launch that happened when color
support is not enabled.

In that case, we need to add the `--

[lldb/test] Fix PExpect.launch issue when disabling color support

This patch should fix a bug in PExpect.launch that happened when color
support is not enabled.

In that case, we need to add the `--no-use-colors` flag to lldb's launch
argument list. However, previously, each character to the string was
appended separately to the `args` list. This patch solves that by adding
the whole string to the list.

This should fix the TestIOHandlerResize failure on GreenDragon.

Differential Revision: https://reviews.llvm.org/D126021

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb/test] Fix failures caused by a previous PExpect.launch change

This should fix the issues introduced by d71d1a9, which skipped all the
test setup commands.

This also fixes the test failures ha

[lldb/test] Fix failures caused by a previous PExpect.launch change

This should fix the issues introduced by d71d1a9, which skipped all the
test setup commands.

This also fixes the test failures happening in TestAutosuggestion.py.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb/Test] Add `use_colors` argument to the PExpect.launch wrapper

This patch adds a new `use_colors` argument to the PExpect.launch
method.

As the name suggests, it allows the user to conditional

[lldb/Test] Add `use_colors` argument to the PExpect.launch wrapper

This patch adds a new `use_colors` argument to the PExpect.launch
method.

As the name suggests, it allows the user to conditionally enable color
support in the debugger, which can be helpful to test functionalities that
rely on that, like progress reporting. It defaults to False.

Differential Revision: https://reviews.llvm.org/D125915

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

show more ...

[lldb/test] Increase pexpect termination timeouts

By default these timeouts are extremely small (0.1s). This means that
100ms after sending an EOF, pexpect will start sending the process
increasingl

[lldb/test] Increase pexpect termination timeouts

By default these timeouts are extremely small (0.1s). This means that
100ms after sending an EOF, pexpect will start sending the process
increasingly aggressive signals, but the small timeouts mean that (on a
loaded machine) the kernel may not have enough time to process the
signal even if the overall effect of the signal is to kill the
application.

It turns out we were already relying on this signals (instead of regular
EOF quits) in our tests. In my experiments it was sufficient to block
SIGINT and SIGHUP to cause some test to become flaky. This was most
likely the reason of a couple of flakes on the lldb-x86_64-debian bot,
and is probably the reason why the pexpect tests are flaky on several
other (e.g. asan) bots.

This patch increses the timeout to 6 seconds (60-fold increase), which
is hopefully sufficient to avoid flakes even in the most extreme
situations.

show more ...

[lldb/driver] Fix SIGTSTP handling

Our SIGTSTP handler was working, but that was mostly accidental.

The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reas

[lldb/driver] Fix SIGTSTP handling

Our SIGTSTP handler was working, but that was mostly accidental.

The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).

Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.

Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.

This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
the thread which is running the handler

This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.

I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.

Differential Revision: https://reviews.llvm.org/D120320

show more ...

[lldb/test] Start pexpect tests with a custom HOME

This addresses the flakyness of (at least) TestMultilineNavigation,
which was failing when the editline history of a concurrently executing
test ma

[lldb/test] Start pexpect tests with a custom HOME

This addresses the flakyness of (at least) TestMultilineNavigation,
which was failing when the editline history of a concurrently executing
test made leaked in. Using a test-specific home directory ensures the
tests are independent.

show more ...

[LLDB] Change pexpect timeout to 30 to 60

Test dependent on pexpect fail randomly with timeouts on Arm/AArch64 Linux
buildbots. I am setting pexpect timeout from 30 to 60.

I will revert this back i

[LLDB] Change pexpect timeout to 30 to 60

Test dependent on pexpect fail randomly with timeouts on Arm/AArch64 Linux
buildbots. I am setting pexpect timeout from 30 to 60.

I will revert this back if this doesnt improve random failures.

show more ...

[lldb] Let TestPExpectTest test the right test class

This test supposed to check the test base we are using for pexpect tests, but instead it used the normal TestBase
class we use for all other test

[lldb] Let TestPExpectTest test the right test class

This test supposed to check the test base we are using for pexpect tests, but instead it used the normal TestBase
class we use for all other tests. TestBase already had the substrs type check since D88792 so this
test was passing because of that.

This just changes the test base of the test to the pexpect one so that the `expect` calls find their intended
target function. Also moves the check to the very start so that we can check the argument without
actually having to start a terminal and all that jazz.

(I found this by accident as D88792 got somehow reverted in a downstream branch so this test started
failing).

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D96556

show more ...

[lldb] Also Catch invalid calls to TestPExpectTest's expect()

This is a follow up to D88792 which found an issue in a call to PExpectTest's
expect function that allows passing a string to the `subst

[lldb] Also Catch invalid calls to TestPExpectTest's expect()

This is a follow up to D88792 which found an issue in a call to PExpectTest's
expect function that allows passing a string to the `substrs` parameter. However
this issue was found by just grepping and TestPExpect's expect function is still
accepting a single string as a value to `substrs`.

This patch adds the same sanity check that D88792 added to the PExpectTest's
implementation of `expect` and also adds a small test for it.

Reviewed By: kastiglione, JDevlieghere

Differential Revision: https://reviews.llvm.org/D89302

show more ...

[lldb/test] Use @skipIfWindows for PExpectTest

Annotating `PExpectTest` with `@skipIfWindows` instead of marking it as an empty class will make the test runner recognize it as a test class, which sh

[lldb/test] Use @skipIfWindows for PExpectTest

Annotating `PExpectTest` with `@skipIfWindows` instead of marking it as an empty class will make the test runner recognize it as a test class, which should allow me to reland adb5c23f8c0d60eeec41dcbe21d1b26184e1c97d.

I don't have a windows machine to verify this works, but I did some tests using `@skipIfLinux` and they all worked as expected. In case the `pexpect` import is not at all available on windows, I moved it to within the method where it's used.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D86745

show more ...

[lldb] Display autosuggestion part in gray if there is one possible suggestion

This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the c

[lldb] Display autosuggestion part in gray if there is one possible suggestion

This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.

Original summary:

I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.

Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.

Reviewed By: teemperor, JDevlieghere, #lldb

Differential Revision: https://reviews.llvm.org/D81001

show more ...

[lldb] Modify the `skipIfRemote` decorator so we can skip all PExpect tests.

This patch modifies the skipIfRemote decorator so it can apply to a
whole class, which allows us to skip all PExpect test

[lldb] Modify the `skipIfRemote` decorator so we can skip all PExpect tests.

This patch modifies the skipIfRemote decorator so it can apply to a
whole class, which allows us to skip all PExpect tests as a whole.

Differential revision: https://reviews.llvm.org/D85365

show more ...

[lldb/pexpect] Force-set the TERM environment variable

In some environments (typically, buildbots), this variable may not be
available. This can cause tests to behave differently.

Explicitly set th

[lldb/pexpect] Force-set the TERM environment variable

In some environments (typically, buildbots), this variable may not be
available. This can cause tests to behave differently.

Explicitly set the variable to "vt100" to ensure consistent test
behavior. It should not matter that we do not inherit the process TERM
variable, as the child process runs in a new virtual terminal anyway.

show more ...

[lldb][NFC] Remove 'from __future__ import print_function' from all tests that don't actually call 'print()'

Summary:
A lot of tests do this trick but the vast majority of them don't even call `prin

[lldb][NFC] Remove 'from __future__ import print_function' from all tests that don't actually call 'print()'

Summary:
A lot of tests do this trick but the vast majority of them don't even call `print()`.

Most of this patch was generated by a script that just looks at all the files and deletes the line if there is no `print (` or `print(` anywhere else in the file.
I checked the remaining tests manually and deleted the import if we never call print (but instead do stuff like `expr print(...)` and similar false-positives).
I also corrected the additional empty lines after the import in the files that I manually edited.

Reviewers: JDevlieghere, labath, jfb

Reviewed By: labath

Subscribers: dexonsmith, wuzish, nemanjai, kbarton, christof, arphaman, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D71452

show more ...

[lldb][test] Prevent \n in calls to lldb's expect() test helper.

Summary:
expect() forwards its command to sendline(). This can be problematic if the command already contains a newline: sendline() u

[lldb][test] Prevent \n in calls to lldb's expect() test helper.

Summary:
expect() forwards its command to sendline(). This can be problematic if the command already contains a newline: sendline() unconditionally adds a newline to the command, which causes the command to run twice (hitting enter in lldb runs the previous command). The expect() helper looks for the prompt and finds the first one, but because the command has run a second time, the buffer will contain the contents of the second time the command ran, causing potential erroneous matching.

Simplify the editline test, which was using different commands to workaround this misunderstanding.

Reviewers: labath

Reviewed By: labath

Subscribers: merge_guards_bot, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D70324

show more ...

Port TestBatchMode to PExpectTest class

Summary:
I'm doing this mainly for consistency, but there are also other cleanups
that will be enabled by this (e.g., the automatic setting of
clang-modules-c

Port TestBatchMode to PExpectTest class

Summary:
I'm doing this mainly for consistency, but there are also other cleanups
that will be enabled by this (e.g., the automatic setting of
clang-modules-cache-path setting).

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D67082

llvm-svn: 370858

show more ...

[test] Make sys.stdout compatible with both Python 2 & 3

This time's the charm.

llvm-svn: 370552

[test] Fix 'argument must be str, not bytes' for Python 3.

Use `sys.stdout.buffer` instead of `sys.stdout` in lldbpexpect.py.

llvm-svn: 370545

[test] Make sure PROMPT is a string

Currently tests using expect_prompt are failing on the Python 3 bot with
an error saying "argument must be str, not bytes". I don't have a Python
3 build handy, b

[test] Make sure PROMPT is a string

Currently tests using expect_prompt are failing on the Python 3 bot with
an error saying "argument must be str, not bytes". I don't have a Python
3 build handy, but I suspect this might fix that.

llvm-svn: 370526

show more ...