*** 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
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
They will dump pretty-print (indentation, extra whitepsace) by default.
I'll make a change to ProcessGDBRemote soon so it stops sending JSON strings
to debugserver pretty-printed; it's unnecessary extra bytes being sent between
the two.
llvm-svn: 276079
This:
a) teaches PythonCallable to look inside a callable object
b) teaches PythonCallable to discover whether a callable method is bound
c) teaches lldb.command to dispatch to either the older 4 argument version or the newer 5 argument version
llvm-svn: 273640
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`. The original code was not escaping the backslashes in the directory path, so this wasn't working.
Differential Revision: http://reviews.llvm.org/D18873
llvm-svn: 265738
Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.
Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18228
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 264351
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
Removed lldb_private::File::Duplicate() and the copy constructor and the assignment operator that used to duplicate the file handles and made them private so no one uses them. Previously the lldb_private::File::Duplicate() function duplicated files that used file descriptors, (int) but not file streams (FILE *), so the lldb_private::File::Duplicate() function only worked some of the time. No one else excep thee ScriptInterpreterPython was using these functions, so that aren't needed nor desired. Previously every time you would drop into the python interpreter we would duplicate files, and now we avoid this file churn.
<rdar://problem/24877720>
llvm-svn: 263161
This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state
The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.
None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself
llvm-svn: 260199
The Visual Studio 2015 build was failing with the following error:
error C2440: 'initializing': cannot convert from 'const char [12]' to 'char *'
This should fix the problem by initializing a non const char array, instead of taking a pointer to const static data.
llvm-svn: 259042
This needs to be able to handle bytes, strings, and bytearray objects.
In Python 2 this was easy because bytes and strings are the same thing,
but in Python 3 the 2 cases need to be handled separately. So as not
to mix raw Python C API code with PythonDataObjects code, I've also
introduced a PythonByteArray class to PythonDataObjects to make the
paradigm used here consistent.
llvm-svn: 258741
* lldb::tid_t was being converted incorrectly, so this is updated to use
PythonInteger instead of manual Python Native API calls.
* OSPlugin_RegisterContextData was assuming that the result of
get_register_data was a string, when in fact it is a bytes. So this
method is updated to use PythonBytes to do the work.
llvm-svn: 257398
Python 3 has lots of new debug asserts, and some of these were
firing on PythonFile. Specifically related to handling of invalid
files.
llvm-svn: 253261
This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception state
upon scope exit.
Additionally, unit tests are included to verify the
feature set of the class.
llvm-svn: 252994
PyCallable is a class that exists solely within the swig wrapper
code. PythonCallable is a more generic implementation of the same
idea that can be used by any Python-related interop code, and lives
in PythonDataObjects.h
The CL is mostly mechanical, and it doesn't cover every possible
user of PyCallable, because I want to minimize the impact of this
change (as well as making it easier to figure out what went wrong
in case this causes a failure). I plan to finish up the rest of
the changes in a subsequent patch, culminating in the removal of
PyCallable entirely.
llvm-svn: 252906
This adds PythonTuple and PythonCallable classes to PythonDataObjects.
Additionally, unit tests are provided that exercise this functionality,
including invoking manipulating and checking for validity of tuples,
and invoking and checking for validity of callables using a variety
of different syntaxes.
The goal here is to eventually replace the code in python-wrapper.swig
that directly uses the Python C API to deal with callables and name
resolution with this code that can be more easily tested and debugged.
llvm-svn: 252787
Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:
Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.
Reviewers: vharron, clayborg, granata.enrico
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D13778
llvm-svn: 250930
Using the Python native C API is non-portable across Python versions,
so this patch changes them to use the `PythonFile` class which hides
the version specific differences behind a single interface.
llvm-svn: 250525
Python file handling got an overhaul in Python 3, and it affects
the way we have to interact with files. Notably:
1) `PyFile_FromFile` no longer exists, and instead we have to use
`PyFile_FromFd`. This means having a way to get an fd from
a FILE*. For this we reuse the lldb_private::File class to
convert between FILE*s and fds, since there are some subtleties
regarding ownership rules when FILE*s and fds refer to the same
file.
2) PyFile is no longer a builtin type, so there is no such thing as
`PyFile_Check`. Instead, files in Python 3 are just instances
of `io.IOBase`. So the logic for checking if something is a file
in Python 3 is to check if it is a subclass of that module.
Additionally, some unit tests are added to verify that `PythonFile`
works as expected on Python 2 and Python 3, and
`ScriptInterpreterPython` is updated to use `PythonFile` instead of
manual calls to the various `PyFile_XXX` methods.
llvm-svn: 250444
Most platforms have "/dev/null". Windows has "nul". Instead of
hardcoding the string /dev/null at various places, make a constant
that contains the correct value depending on the platform, and use
that everywhere instead.
llvm-svn: 250331
There were a couple of issues related to string handling that
needed to be fixed. In particular, we cannot get away with
converting `PyUnicode` objects to `PyBytes` objects and storing
the `PyBytes` regardless of Python version. Instead we have to
store a `PyUnicode` on Python 3 and a `PyString` on Python 2.
The reason for this is that if you call `PyObject_Str` on a
`PyBytes` in Python 3, it will return you a string that actually
contains the string value wrappedin the characters b''. So if we
create a `PythonString` with the value "test", and we call Str()
on it, we will get back the string "b'test'", which breaks string
equality. The only way to fix this is to store a native
`PyUnicode` object under Python 3.
With this CL, ScriptInterpreterPythonTests unit tests pass 100%
under Python 2 and Python 3.
llvm-svn: 250327
Python 3 reverses the order in which you must call Py_InitializeEx
and PyEval_InitThreads. Since that log is in itself already a
little nuanced, it is refactored into a function so that the reversal
is more clear. At the same time, there's a lot of logic during
Python initialization to save off a bunch of state and then restore
it after initialization is complete. To express this more cleanly,
it is refactored to an RAII-style pattern where state is saved off
on acquisition and restored on release.
llvm-svn: 250306
Added a constructor that takes list_size for `PythonList`.
Made all single-argument constructors explicit.
Re-ordered constructors to be consistent with other classes.
llvm-svn: 250304
