Convert FileSystem::Open() to return Expected<FileUP>

Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm

Convert FileSystem::Open() to return Expected<FileUP>

Summary:
This patch converts FileSystem::Open from this prototype:

Status
Open(File &File, const FileSpec &file_spec, ...);

to this one:

llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);

This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: labath

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 373003

show more ...

Add PythonBoolean type to the PythonDataObjects

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

llvm-svn: 354206

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[FileSystem] Open File instances through the FileSystem.

This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virt

[FileSystem] Open File instances through the FileSystem.

This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virtual file system. This is needed in order to make things work with
the VFS in the future.

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

llvm-svn: 346049

show more ...

Added new API to SBStructuredData class

Summary:
- Added API to access data types
-- integer, double, array, string, boolean and dictionary data types
-- Earlier user had to parse through t

Added new API to SBStructuredData class

Summary:
- Added API to access data types
-- integer, double, array, string, boolean and dictionary data types
-- Earlier user had to parse through the string output to get these
values

- Added Test cases for API testing

- Added new StructuredDataType enum in public include file
-- Replaced locally-defined enum in StructuredData.h with this new
one
-- Modified other internal files using this locally-defined enum

Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>

Reviewers: clayborg, lldb-commits

Reviewed By: clayborg

Subscribers: labath

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

llvm-svn: 304138

show more ...

Fix some unit test compilation failures.

llvm-svn: 287158

Don't allow direct access to StreamString's internal buffer.

This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and inst

Don't allow direct access to StreamString's internal buffer.

This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.

Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.

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

llvm-svn: 287152

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

Fix unit tests on windows

Python headers need to be included before PosixApi.h

llvm-svn: 278345

Fix a problem where if a uint64_t value is placed into a python dictionary and sent up to LLDB and converted to StructuredData, it would not be able to parse the full 64 bit value. A number like 0xf0

Fix a problem where if a uint64_t value is placed into a python dictionary and sent up to LLDB and converted to StructuredData, it would not be able to parse the full 64 bit value. A number like 0xf000000000000000L could be placed into a dictionary, and sent to LLDB and it would end up being 0xffffffffffffffff since it would overflow a int64_t. We leave the old code there, but if it overflows, we treat the number like a uint64_t and get it to decode correctly. Added a gtest to cover this so we don't regress. I verified the gtest failed prior to the fix, and it succeeds after it.

<rdar://problem/27409265>

llvm-svn: 278304

show more ...

Fix PythonDataObjectsTests for python 2

Summary:
the python2 branch seems erroneous as it expected the object to be both a "String" and "Bytes".
Fix the expectation.

Reviewers: zturner

Subscribers

Fix PythonDataObjectsTests for python 2

Summary:
the python2 branch seems erroneous as it expected the object to be both a "String" and "Bytes".
Fix the expectation.

Reviewers: zturner

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D17545

llvm-svn: 261901

show more ...

Fix sign conversion warnings in LLDB Python unittests

llvm-svn: 259689

Fix swig typemap for SBEvent.

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 cas

Fix swig typemap for SBEvent.

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

show more ...

Introduce a PythonBytes class into PythonDataObjects.

This class behaves the same as PythonString on Python2, but differently
on Python3. Unittests are added as well.

llvm-svn: 257397

gtest - Make a `PythonTestSuite` base class for setup / teardown.

This allows other potential unit test suites (of which one is
forthcoming in a subsequent patch) to re-use the same initialization
a

gtest - Make a `PythonTestSuite` base class for setup / teardown.

This allows other potential unit test suites (of which one is
forthcoming in a subsequent patch) to re-use the same initialization
and teardown of the GIL.

llvm-svn: 252993

show more ...

Create `PythonTuple` and `PythonCallable` wrapper classes.

This adds PythonTuple and PythonCallable classes to PythonDataObjects.
Additionally, unit tests are provided that exercise this functionali

Create `PythonTuple` and `PythonCallable` wrapper classes.

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

show more ...

Add a `PythonModule` class, and a root-level method for resolving names.

llvm-svn: 252765

Convert SWIG typemap string operations to PythonObjects.

llvm-svn: 250530

Introduce a `PythonFile` object, and use it everywhere.

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 lo

Introduce a `PythonFile` object, and use it everywhere.

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

show more ...

Get Python unit tests working with Python 3.

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

Get Python unit tests working with Python 3.

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

show more ...

Fix ref counting of Python objects.

PythonObjects were being incorrectly ref-counted. This problem was
pervasive throughout the codebase, leading to an unknown number of memory
leaks and potentially

Fix ref counting of Python objects.

PythonObjects were being incorrectly ref-counted. This problem was
pervasive throughout the codebase, leading to an unknown number of memory
leaks and potentially use-after-free.

The issue stems from the fact that Python native methods can either return
"borrowed" references or "owned" references. For the former category, you
*must* incref it prior to decrefing it. And for the latter category, you
should not incref it before decrefing it. This is mostly an issue when a
Python C API method returns a `PyObject` to you, but it can also happen with
a method accepts a `PyObject`. Notably, this happens in `PyList_SetItem`,
which is documented to "steal" the reference that you give it. So if you
pass something to `PyList_SetItem`, you cannot hold onto it unless you
incref it first. But since this is one of only two exceptions in the
entire API, it's confusing and difficult to remember.

Our `PythonObject` class was indiscriminantely increfing every object it
received, which means that if you passed it an owned reference, you now
have a dangling reference since owned references should not be increfed.
We were doing this in quite a few places.

There was also a fair amount of manual increfing and decrefing prevalent
throughout the codebase, which is easy to get wrong.

This patch solves the problem by making any construction of a
`PythonObject` from a `PyObject` take a flag which indicates whether it is
an owned reference or a borrowed reference. There is no way to construct a
`PythonObject` without this flag, and it does not offer a default value,
forcing the user to make an explicit decision every time.

All manual uses of `PyObject` have been cleaned up throughout the codebase
and replaced with `PythonObject` in order to make RAII the predominant
pattern when dealing with native Python objects.

Differential Revision: http://reviews.llvm.org/D13617
Reviewed By: Greg Clayton

llvm-svn: 250195

show more ...

Port native Python-API to 3.x

With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x,

Port native Python-API to 3.x

With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:

1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.

Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.

llvm-svn: 249886

show more ...