[lldb] Format more Python files with black (#65979)

By running this from lldb/

$ black --exclude "third_party/|scripts/|utils/" ./

Fix `script -lpython` to handle control flow in one-line commands.

The fix is to append a newline to the source being evaluated.

Without this patch, the following commands **print no output, no err

Fix `script -lpython` to handle control flow in one-line commands.

The fix is to append a newline to the source being evaluated.

Without this patch, the following commands **print no output, no errors**.

```
(lldb) script if "foo" in lldb.frame.name: print(lldb.thread)
(lldb) script for f in lldb.thread: print(f.name)
```

The issue is with `code.InteractiveConsole.runsource()`. A trailing newline is
needed for these expressions to be evaluated. I don't know why this is, the
docs don't mention anything.

From a python repl, the following samples show that a terminal newline allows
statements containing flow control to fully execute.

```
>>> import code
>>> repl = code.InteractiveConsole()
>>> repl.runsource("if True: print(1)")
True
>>> repl.runsource("if True: print(1)\n")
1
False
```

Notes:

From an interactive python repl, the output is not printed immediately. The
user is required to enter a blank line following the first.

```
>>> if True: print(1)
...
1
```

However, `python -c 'if True: print(1)'` works without needing a newline.

Reviewed By: JDevlieghere

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

show more ...

[lldb] Don't overwrite quit and exit builtins in the Python interpreter

The interactive interpreter is overwriting the exit and quit builtins
with an instance of LLDBQuitter in order to make exit an

[lldb] Don't overwrite quit and exit builtins in the Python interpreter

The interactive interpreter is overwriting the exit and quit builtins
with an instance of LLDBQuitter in order to make exit and quit behave
like exit() and quit(). It does that by overwriting the __repr__
function to call itself.

Despite being a neat trick, it has the unintentional side effect that
printing these builtins now quits the interpreter:

(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> print(exit)
(lldb)

You might consider the above example slightly convoluted, but a more
realistic situation is calling locals():

(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> locals()
(lldb)

This patch keeps the existing behavior but without overwriting the
builtins. Instead, it looks for quit and exit in the input. If they're
present, we exit the interpreter with the help of an exception.

The previous implementation also used globals to differentiate between
exit getting called from the interactive interpreter or from inside a
script. This patch achieves the same by using a different exception in
for the interpreter case.

rdar://84095490

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

show more ...

[lldb/Python] Fix the infinitely looping Python prompt bug

Executing commands below will get you bombarded by a wall of Python
command prompts (>>> ).

$ echo 'foo' | ./bin/lldb -o script
$ cat /tmp

[lldb/Python] Fix the infinitely looping Python prompt bug

Executing commands below will get you bombarded by a wall of Python
command prompts (>>> ).

$ echo 'foo' | ./bin/lldb -o script
$ cat /tmp/script
script
print("foo")
$ lldb --source /tmp/script

The issue is that our custom input reader doesn't handle EOF. According
to the Python documentation, file.readline always includes a trailing
newline character unless the file ends with an incomplete line. An empty
string signals EOF. This patch raises an EOFError when that happens.

[1] https://docs.python.org/2/library/stdtypes.html#file.readline

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

show more ...

[Python] Flush prompt before reading input

Make sure the prompt has been flushed before reading commands. Buffering
is different in Python 3, which led to the prompt not being displayed in
the Xcode

[Python] Flush prompt before reading input

Make sure the prompt has been flushed before reading commands. Buffering
is different in Python 3, which led to the prompt not being displayed in
the Xcode console.

llvm-svn: 364335

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 ...

Make some more of the LLDB/SWIG/Python glue Python 3 aware.

Mostly this is just converting some print statements to print
functions.

llvm-svn: 250533

Continuation broken for Python scripts when using non-interactive input (Xcode for example).

The problem was the read_func we were supplying to the interactive interpreter wasn't stripping the newl

Continuation broken for Python scripts when using non-interactive input (Xcode for example).

The problem was the read_func we were supplying to the interactive interpreter wasn't stripping the newline from the end of the string. Now it does and multi-line python scripts can be typed in Xcode.

<rdar://problem/17696438>

llvm-svn: 217843

show more ...

Suppress python readline module under Linux to fix a seg fault.

Bug fix for pr18841:
http://llvm.org/bugs/show_bug.cgi?id=18841

This change creates a stub Python readline.so module that does almost

Suppress python readline module under Linux to fix a seg fault.

Bug fix for pr18841:
http://llvm.org/bugs/show_bug.cgi?id=18841

This change creates a stub Python readline.so module that does almost
nothing. Its whole purpose is to prevent Python from loading the real
module, something it does during the embedded Python interpreter's
initialization sequence (and way before lldb ever requests it within
embedded_interpreter.py).

On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the
stock Python readline module links against the GNU readline library.
This appears to be the case on all Pythons except where __APPLE__ is
defined. LLDB now requires linking against the libedit library.
Something about having both libedit.so and libreadline.so linked into
the same process space is causing the Python readline.so to trigger a
NULL memory access. I have put in a separate patch to python.org.

This suppression of embedded interpreter readline support can be
removed if at least any one of the following happens:

1. The stock python distribution accepts a patch similar to what I
submitted to Python 2.7.6's Modules/readline.c file.

2. The stock python distribution implements Modules/readline.c in
terms of libedit's readline compatibility mode (i.e. essentially
compiles it the way __APPLE__ compiles that module) under Linux.

3. a clean-room implementation of the python readline module is
implemented against libedit (either readline compatibility mode or
native libedit). This could be implemented within the readline.cpp
file that this change introduces. It cannot be a fork of python's
readline.c module due to llvm licensing.

The net effect of this change on Linux is that the embedded python's
readline support will not exist.

llvm-svn: 202243

show more ...

Merging the iohandler branch back into main.

The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embe

Merging the iohandler branch back into main.

The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)

We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.

llvm-svn: 200263

show more ...

Add a new-line

llvm-svn: 197860

Split up the Python script interpreter code to allow multiple script interpreter objects to
exist within the same process (one script interpreter object per debugger object). The
python script inter

Split up the Python script interpreter code to allow multiple script interpreter objects to
exist within the same process (one script interpreter object per debugger object). The
python script interpreter objects are all using the same global Python script interpreter;
they use separate dictionaries to keep their data separate, and mutex's to prevent any object
attempting to use the global Python interpreter when another object is already using it.

llvm-svn: 123415

show more ...

Committing patch from Joseph Ranieri to handle 'exit()' the same
as 'quit()' in the python script environment.

llvm-svn: 105756

Initial checkin of lldb code from internal Apple repo.

llvm-svn: 105619