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
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
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
*** 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
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
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
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
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
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
Jonas Devlieghere