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
2015-11-06 03:22:28 +08:00
|
|
|
from __future__ import absolute_import
|
2015-10-24 01:04:29 +08:00
|
|
|
|
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
2015-11-06 03:22:28 +08:00
|
|
|
# System modules
|
2019-12-20 22:11:49 +08:00
|
|
|
import os
|
2015-02-03 06:12:39 +08:00
|
|
|
import sys
|
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
2015-11-06 03:22:28 +08:00
|
|
|
|
|
|
|
# Third-party modules
|
2016-01-28 02:49:25 +08:00
|
|
|
import six
|
2015-02-03 06:12:39 +08:00
|
|
|
|
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
2015-11-06 03:22:28 +08:00
|
|
|
# LLDB Modules
|
|
|
|
import lldb
|
|
|
|
from .lldbtest import *
|
|
|
|
from . import lldbutil
|
2020-08-06 06:20:53 +08:00
|
|
|
from lldbsuite.test.decorators import *
|
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
2015-11-06 03:22:28 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
@skipIfRemote
|
|
|
|
@skipIfWindows # llvm.org/pr22274: need a pexpect replacement for windows
|
|
|
|
class PExpectTest(TestBase):
|
2016-01-28 02:49:25 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
NO_DEBUG_INFO_TESTCASE = True
|
|
|
|
PROMPT = "(lldb) "
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
def expect_prompt(self):
|
|
|
|
self.child.expect_exact(self.PROMPT)
|
2015-02-03 06:12:39 +08:00
|
|
|
|
2021-08-02 09:31:52 +08:00
|
|
|
def launch(self, executable=None, extra_args=None, timeout=60, dimensions=None):
|
2020-08-29 02:41:07 +08:00
|
|
|
logfile = getattr(sys.stdout, 'buffer',
|
|
|
|
sys.stdout) if self.TraceOn() else None
|
2016-01-28 02:49:25 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
args = ['--no-lldbinit', '--no-use-colors']
|
|
|
|
for cmd in self.setUpCommands():
|
|
|
|
args += ['-O', cmd]
|
|
|
|
if executable is not None:
|
|
|
|
args += ['--file', executable]
|
|
|
|
if extra_args is not None:
|
|
|
|
args.extend(extra_args)
|
2019-12-20 22:11:49 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
env = dict(os.environ)
|
2021-09-14 21:13:51 +08:00
|
|
|
env["TERM"] = "vt100"
|
|
|
|
env["HOME"] = self.getBuildDir()
|
2019-12-20 22:11:49 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
import pexpect
|
|
|
|
self.child = pexpect.spawn(
|
|
|
|
lldbtest_config.lldbExec, args=args, logfile=logfile,
|
|
|
|
timeout=timeout, dimensions=dimensions, env=env)
|
|
|
|
self.expect_prompt()
|
|
|
|
for cmd in self.setUpCommands():
|
|
|
|
self.child.expect_exact(cmd)
|
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
2019-08-30 17:07:42 +08:00
|
|
|
self.expect_prompt()
|
2020-08-29 02:41:07 +08:00
|
|
|
if executable is not None:
|
|
|
|
self.child.expect_exact("target create")
|
|
|
|
self.child.expect_exact("Current executable set to")
|
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
2019-08-30 17:07:42 +08:00
|
|
|
self.expect_prompt()
|
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
def expect(self, cmd, substrs=None):
|
|
|
|
self.assertNotIn('\n', cmd)
|
2020-11-05 20:41:26 +08:00
|
|
|
# If 'substrs' is a string then this code would just check that every
|
|
|
|
# character of the string is in the output.
|
|
|
|
assert not isinstance(substrs, six.string_types), \
|
|
|
|
"substrs must be a collection of strings"
|
2021-02-12 15:51:43 +08:00
|
|
|
|
|
|
|
self.child.sendline(cmd)
|
2020-08-29 02:41:07 +08:00
|
|
|
if substrs is not None:
|
|
|
|
for s in substrs:
|
|
|
|
self.child.expect_exact(s)
|
|
|
|
self.expect_prompt()
|
|
|
|
|
|
|
|
def quit(self, gracefully=True):
|
|
|
|
self.child.sendeof()
|
|
|
|
self.child.close(force=not gracefully)
|
|
|
|
self.child = None
|
[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
2020-08-12 18:54:28 +08:00
|
|
|
|
2020-08-29 02:41:07 +08:00
|
|
|
def cursor_forward_escape_seq(self, chars_to_move):
|
|
|
|
"""
|
|
|
|
Returns the escape sequence to move the cursor forward/right
|
|
|
|
by a certain amount of characters.
|
|
|
|
"""
|
|
|
|
return b"\x1b\[" + str(chars_to_move).encode("utf-8") + b"C"
|