dotest: improvements to the pexpect tests

Summary:
While working on r370054, i've found it frustrating that the test output
was compeletely unhelpful in case of failures. Therefore I've decided to
i

dotest: improvements to the pexpect tests

Summary:
While working on r370054, i've found it frustrating that the test output
was compeletely unhelpful in case of failures. Therefore I've decided to
improve that. In this I reuse the PExpectTest class, which was one of
our mechanisms for running pexpect tests, but which has gotten orhpaned
in the mean time.

I've replaced the existing send methods with a "expect" method, which
I've tried to design so that it has a similar interface to the expect
method in regular non-pexpect dotest tests (as it essentially does
something very similar). I've kept the ability to dump the transcript of
the pexpect communication to stdout in the "trace" mode, as that is a
very handy way to figure out what the test is doing. I've also removed
the "expect_string" method used in the existing tests -- I've found this
to be unhelpful because it hides the message that would be normally
displayed by the EOF exception. Although vebose, this message includes
some important information, like what strings we were searching for,
what were the last bits of lldb output, etc. I've also beefed up the
class to automatically disable the debug info test duplication, and
auto-skip tests when the host platform does not support pexpect.

This patch ports TestMultilineCompletion and TestIOHandlerCompletion to
the new class. It also deletes TestFormats as it is not testing anything
(definitely not formats) -- it was committed with the test code
commented out (r228207), and then the testing code was deleted in
r356000.

Reviewers: teemperor, JDevlieghere, davide

Subscribers: aprantl, lldb-commits

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

llvm-svn: 370449

show more ...

[lldb][NFC] Remove unused imports in python tests

llvm-svn: 367663

Fix flakyness in TestCommandScriptImmediateOutput

I'm not sure why this surfaced at this particular point, but
TestCommandScriptImmediateOutput (a pexpect test) had a synchronization
issue, where th

Fix flakyness in TestCommandScriptImmediateOutput

I'm not sure why this surfaced at this particular point, but
TestCommandScriptImmediateOutput (a pexpect test) had a synchronization
issue, where the (lldb) promts it was expecting were getting out of
sync. This happened for two reasons:
- it did not expect the initial (lldb) prompt we print at startup
- launchArgs() returned None, which resulted in an extra "target create
None" command being issued to lldb (and an extra unhandled prompt
being printed).

Resolving these two issues seems to fix (or at least, improve) the test.

llvm-svn: 357459

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Fixed the failing test TestCommandScriptImmediateOutput on MacOSX. Turns out that there are few things to watch out for when writing pexpect tests:

1 - If you plan on looking for the "(lldb) " promp

Fixed the failing test TestCommandScriptImmediateOutput on MacOSX. Turns out that there are few things to watch out for when writing pexpect tests:

1 - If you plan on looking for the "(lldb) " prompt as a regular expression, look for "\(lldb\) " so you don't just find "lldb".
2 - Make sure to not use colors (specify --no-use-colors as an option to lldb when launching it) as our editline will print:

"(lldb) <color junk>(lldb) "

where "<color junk>" is a work around that is used to allow us to colorize our prompts. The bad thing is this will make pexepct code like this not execute as you would expect:

prompt = "\(lldb\) "
self.child.sendline("breakpoint set ...", prompt)
self.child.sendline("breakpoint clear ...", prompt)

The problem is the first "sendline" will create two lldb prompts and will match both the first and second prompts and you output will get off. So be sure to disable colors if you need to.

Fixed a case where "TestCommandScriptImmediateOutput.py" would fail if you have spaces in your directory names. I modified custom_command.py to use shlex to parse arguments and I quoted the file path we sent down to the custom_command.write_file function.

llvm-svn: 264810

show more ...

Don't automtically try to import pexpect in lldbpexpect.

Since pexpect doesn't exist on Windows, tests which are xfail'ed
are not being run at all because they are failing when the file
is imported

Don't automtically try to import pexpect in lldbpexpect.

Since pexpect doesn't exist on Windows, tests which are xfail'ed
are not being run at all because they are failing when the file
is imported due to the `import pexpect`. This puts the import
behind a conditional and makes an empty base class in the case
where pexpect is not present.

llvm-svn: 258965

show more ...

Python 3 - Turn on absolute imports, and fix existing imports.

Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3

Python 3 - Turn on absolute imports, and fix existing imports.

Absolute imports were introduced in Python 2.5 as a feature
(e.g. from __future__ import absolute_import), and made default
in Python 3.

When absolute imports are enabled, the import system changes in
a couple of ways:

1) The `import foo` syntax will *only* search sys.path. If `foo`
isn't in sys.path, it won't be found. Period. Without absolute
imports, the import system will also search the same directory
that the importing file resides in, so that you can easily
import from the same folder.

2) From inside a package, you can use a dot syntax to refer to higher
levels of the current package. For example, if you are in the
package lldbsuite.test.utility, then ..foo refers to
lldbsuite.test.foo. You can use this notation with the
`from X import Y` syntax to write intra-package references. For
example, using the previous locationa s a starting point, writing
`from ..support import seven` would import lldbsuite.support.seven

Since this is now the default behavior in Python 3, this means that
importing from the same directory with `import foo` *no longer works*.
As a result, the only way to have portable code is to force absolute
imports for all versions of Python.

See PEP 0328 [https://www.python.org/dev/peps/pep-0328/] for more
information about absolute and relative imports.

Differential Revision: http://reviews.llvm.org/D14342
Reviewed By: Todd Fiala

llvm-svn: 252191

show more ...

Remove `use_lldb_suite` from the package, and don't import it anymore.

This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
li

Remove `use_lldb_suite` from the package, and don't import it anymore.

This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.

To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`

llvm-svn: 251963

show more ...

Move lldb/test to lldb/packages/Python/lldbsuite/test.

This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but m

Move lldb/test to lldb/packages/Python/lldbsuite/test.

This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).

llvm-svn: 251532

show more ...