2015-10-24 01:08:35 +00:00
|
|
|
//===-- PythonDataObjects.h--------------------------------------*- C++ -*-===//
|
2012-08-23 22:02:23 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2012-08-23 22:02:23 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
//
|
|
|
|
|
// !! FIXME FIXME FIXME !!
|
|
|
|
|
//
|
|
|
|
|
// Python APIs nearly all can return an exception. They do this
|
|
|
|
|
// by returning NULL, or -1, or some such value and setting
|
|
|
|
|
// the exception state with PyErr_Set*(). Exceptions must be
|
|
|
|
|
// handled before further python API functions are called. Failure
|
|
|
|
|
// to do so will result in asserts on debug builds of python.
|
|
|
|
|
// It will also sometimes, but not usually result in crashes of
|
|
|
|
|
// release builds.
|
|
|
|
|
//
|
|
|
|
|
// Nearly all the code in this header does not handle python exceptions
|
|
|
|
|
// correctly. It should all be converted to return Expected<> or
|
|
|
|
|
// Error types to capture the exception.
|
|
|
|
|
//
|
|
|
|
|
// Everything in this file except functions that return Error or
|
|
|
|
|
// Expected<> is considered deprecated and should not be
|
|
|
|
|
// used in new code. If you need to use it, fix it first.
|
|
|
|
|
//
|
2019-10-15 17:12:49 +00:00
|
|
|
//
|
|
|
|
|
// TODOs for this file
|
|
|
|
|
//
|
|
|
|
|
// * Make all methods safe for exceptions.
|
|
|
|
|
//
|
|
|
|
|
// * Eliminate method signatures that must translate exceptions into
|
|
|
|
|
// empty objects or NULLs. Almost everything here should return
|
|
|
|
|
// Expected<>. It should be acceptable for certain operations that
|
|
|
|
|
// can never fail to assert instead, such as the creation of
|
|
|
|
|
// PythonString from a string literal.
|
|
|
|
|
//
|
2020-04-07 01:06:02 +09:00
|
|
|
// * Eliminate Reset(), and make all non-default constructors private.
|
2019-10-15 17:12:49 +00:00
|
|
|
// Python objects should be created with Retain<> or Take<>, and they
|
|
|
|
|
// should be assigned with operator=
|
|
|
|
|
//
|
|
|
|
|
// * Eliminate default constructors, make python objects always
|
|
|
|
|
// nonnull, and use optionals where necessary.
|
|
|
|
|
//
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
|
2015-07-30 20:28:07 +00:00
|
|
|
#ifndef LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H
|
|
|
|
|
#define LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H
|
2012-08-23 22:02:23 +00:00
|
|
|
|
2019-12-10 08:54:30 -08:00
|
|
|
#include "lldb/Host/Config.h"
|
|
|
|
|
|
2019-12-13 10:37:33 -08:00
|
|
|
#if LLDB_ENABLE_PYTHON
|
2018-06-21 17:36:32 +00:00
|
|
|
|
2016-08-19 20:44:07 +00:00
|
|
|
// LLDB Python header must be included first
|
|
|
|
|
#include "lldb-python.h"
|
|
|
|
|
|
2015-10-15 19:35:48 +00:00
|
|
|
#include "lldb/Host/File.h"
|
2017-06-27 10:45:31 +00:00
|
|
|
#include "lldb/Utility/StructuredData.h"
|
2012-08-23 22:02:23 +00:00
|
|
|
|
2016-01-11 22:16:12 +00:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
|
|
|
|
|
2012-08-23 22:02:23 +00:00
|
|
|
namespace lldb_private {
|
2019-10-22 02:32:37 +00:00
|
|
|
namespace python {
|
2015-10-24 01:08:35 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
class PythonObject;
|
2016-01-11 22:16:12 +00:00
|
|
|
class PythonBytes;
|
2015-03-17 20:04:04 +00:00
|
|
|
class PythonString;
|
|
|
|
|
class PythonList;
|
|
|
|
|
class PythonDictionary;
|
|
|
|
|
class PythonInteger;
|
2019-10-08 17:56:18 +00:00
|
|
|
class PythonException;
|
2015-03-17 20:04:04 +00:00
|
|
|
|
|
|
|
|
class StructuredPythonObject : public StructuredData::Generic {
|
2015-10-24 01:08:35 +00:00
|
|
|
public:
|
2015-03-17 20:04:04 +00:00
|
|
|
StructuredPythonObject() : StructuredData::Generic() {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-17 20:04:04 +00:00
|
|
|
StructuredPythonObject(void *obj) : StructuredData::Generic(obj) {
|
|
|
|
|
Py_XINCREF(GetValue());
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-24 01:08:35 +00:00
|
|
|
~StructuredPythonObject() override {
|
2015-03-17 20:04:04 +00:00
|
|
|
if (Py_IsInitialized())
|
|
|
|
|
Py_XDECREF(GetValue());
|
|
|
|
|
SetValue(nullptr);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-17 20:04:04 +00:00
|
|
|
bool IsValid() const override { return GetValue() && GetValue() != Py_None; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-01 17:41:48 +00:00
|
|
|
void Serialize(llvm::json::OStream &s) const override;
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2015-10-24 01:08:35 +00:00
|
|
|
private:
|
2015-03-17 20:04:04 +00:00
|
|
|
DISALLOW_COPY_AND_ASSIGN(StructuredPythonObject);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum class PyObjectType {
|
|
|
|
|
Unknown,
|
|
|
|
|
None,
|
2019-02-16 18:39:14 +00:00
|
|
|
Boolean,
|
2015-03-17 20:04:04 +00:00
|
|
|
Integer,
|
|
|
|
|
Dictionary,
|
|
|
|
|
List,
|
2015-10-15 19:35:48 +00:00
|
|
|
String,
|
2016-01-11 22:16:12 +00:00
|
|
|
Bytes,
|
2016-01-25 23:21:09 +00:00
|
|
|
ByteArray,
|
2015-11-11 17:59:49 +00:00
|
|
|
Module,
|
2015-11-11 19:42:27 +00:00
|
|
|
Callable,
|
|
|
|
|
Tuple,
|
2015-10-15 19:35:48 +00:00
|
|
|
File
|
2015-03-17 20:04:04 +00:00
|
|
|
};
|
|
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
enum class PyRefType {
|
|
|
|
|
Borrowed, // We are not given ownership of the incoming PyObject.
|
|
|
|
|
// We cannot safely hold it without calling Py_INCREF.
|
|
|
|
|
Owned // We have ownership of the incoming PyObject. We should
|
|
|
|
|
// not call Py_INCREF.
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
|
|
|
|
|
// Take a reference that you already own, and turn it into
|
|
|
|
|
// a PythonObject.
|
|
|
|
|
//
|
|
|
|
|
// Most python API methods will return a +1 reference
|
|
|
|
|
// if they succeed or NULL if and only if
|
|
|
|
|
// they set an exception. Use this to collect such return
|
|
|
|
|
// values, after checking for NULL.
|
|
|
|
|
//
|
|
|
|
|
// If T is not just PythonObject, then obj must be already be
|
|
|
|
|
// checked to be of the correct type.
|
|
|
|
|
template <typename T> T Take(PyObject *obj) {
|
|
|
|
|
assert(obj);
|
|
|
|
|
assert(!PyErr_Occurred());
|
|
|
|
|
T thing(PyRefType::Owned, obj);
|
|
|
|
|
assert(thing.IsValid());
|
2019-11-12 14:33:52 +01:00
|
|
|
return thing;
|
2019-10-08 17:56:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Retain a reference you have borrowed, and turn it into
|
|
|
|
|
// a PythonObject.
|
|
|
|
|
//
|
|
|
|
|
// A minority of python APIs return a borrowed reference
|
|
|
|
|
// instead of a +1. They will also return NULL if and only
|
|
|
|
|
// if they set an exception. Use this to collect such return
|
|
|
|
|
// values, after checking for NULL.
|
|
|
|
|
//
|
|
|
|
|
// If T is not just PythonObject, then obj must be already be
|
|
|
|
|
// checked to be of the correct type.
|
|
|
|
|
template <typename T> T Retain(PyObject *obj) {
|
|
|
|
|
assert(obj);
|
|
|
|
|
assert(!PyErr_Occurred());
|
|
|
|
|
T thing(PyRefType::Borrowed, obj);
|
|
|
|
|
assert(thing.IsValid());
|
2019-11-12 14:33:52 +01:00
|
|
|
return thing;
|
2019-10-08 17:56:18 +00:00
|
|
|
}
|
|
|
|
|
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
// This class can be used like a utility function to convert from
|
|
|
|
|
// a llvm-friendly Twine into a null-terminated const char *,
|
|
|
|
|
// which is the form python C APIs want their strings in.
|
|
|
|
|
//
|
|
|
|
|
// Example:
|
|
|
|
|
// const llvm::Twine &some_twine;
|
|
|
|
|
// PyFoo_Bar(x, y, z, NullTerminated(some_twine));
|
|
|
|
|
//
|
|
|
|
|
// Why a class instead of a function? If the twine isn't already null
|
|
|
|
|
// terminated, it will need a temporary buffer to copy the string
|
|
|
|
|
// into. We need that buffer to stick around for the lifetime of the
|
|
|
|
|
// statement.
|
|
|
|
|
class NullTerminated {
|
|
|
|
|
const char *str;
|
|
|
|
|
llvm::SmallString<32> storage;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
NullTerminated(const llvm::Twine &twine) {
|
|
|
|
|
llvm::StringRef ref = twine.toNullTerminatedStringRef(storage);
|
|
|
|
|
str = ref.begin();
|
|
|
|
|
}
|
|
|
|
|
operator const char *() { return str; }
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-22 02:32:37 +00:00
|
|
|
inline llvm::Error nullDeref() {
|
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
|
"A NULL PyObject* was dereferenced");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline llvm::Error exception(const char *s = nullptr) {
|
|
|
|
|
return llvm::make_error<PythonException>(s);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
inline llvm::Error keyError() {
|
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
|
"key not in dict");
|
|
|
|
|
}
|
2019-10-08 17:56:18 +00:00
|
|
|
|
2019-10-28 21:59:04 -07:00
|
|
|
#if PY_MAJOR_VERSION < 3
|
|
|
|
|
// The python 2 API declares some arguments as char* that should
|
|
|
|
|
// be const char *, but it doesn't actually modify them.
|
|
|
|
|
inline char *py2_const_cast(const char *s) { return const_cast<char *>(s); }
|
|
|
|
|
#else
|
|
|
|
|
inline const char *py2_const_cast(const char *s) { return s; }
|
|
|
|
|
#endif
|
|
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
enum class PyInitialValue { Invalid, Empty };
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
template <typename T, typename Enable = void> struct PythonFormat;
|
|
|
|
|
|
|
|
|
|
template <> struct PythonFormat<unsigned long long> {
|
|
|
|
|
static constexpr char format = 'K';
|
|
|
|
|
static auto get(unsigned long long value) { return value; }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
template <> struct PythonFormat<long long> {
|
|
|
|
|
static constexpr char format = 'L';
|
|
|
|
|
static auto get(long long value) { return value; }
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-22 02:32:37 +00:00
|
|
|
template <> struct PythonFormat<PyObject *> {
|
|
|
|
|
static constexpr char format = 'O';
|
|
|
|
|
static auto get(PyObject *value) { return value; }
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
template <typename T>
|
|
|
|
|
struct PythonFormat<
|
|
|
|
|
T, typename std::enable_if<std::is_base_of<PythonObject, T>::value>::type> {
|
|
|
|
|
static constexpr char format = 'O';
|
|
|
|
|
static auto get(const T &value) { return value.get(); }
|
|
|
|
|
};
|
|
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
class PythonObject {
|
|
|
|
|
public:
|
|
|
|
|
PythonObject() : m_py_obj(nullptr) {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-22 02:32:37 +00:00
|
|
|
PythonObject(PyRefType type, PyObject *py_obj) {
|
|
|
|
|
m_py_obj = py_obj;
|
|
|
|
|
// If this is a borrowed reference, we need to convert it to
|
|
|
|
|
// an owned reference by incrementing it. If it is an owned
|
|
|
|
|
// reference (for example the caller allocated it with PyDict_New()
|
|
|
|
|
// then we must *not* increment it.
|
|
|
|
|
if (m_py_obj && Py_IsInitialized() && type == PyRefType::Borrowed)
|
|
|
|
|
Py_XINCREF(m_py_obj);
|
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
2015-10-13 18:16:15 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-17 22:22:09 +00:00
|
|
|
PythonObject(const PythonObject &rhs)
|
|
|
|
|
: PythonObject(PyRefType::Borrowed, rhs.m_py_obj) {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
PythonObject(PythonObject &&rhs) {
|
|
|
|
|
m_py_obj = rhs.m_py_obj;
|
|
|
|
|
rhs.m_py_obj = nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
~PythonObject() { Reset(); }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
void Reset() {
|
2019-10-08 17:56:18 +00:00
|
|
|
if (m_py_obj && Py_IsInitialized())
|
|
|
|
|
Py_DECREF(m_py_obj);
|
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
2015-10-13 18:16:15 +00:00
|
|
|
m_py_obj = nullptr;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
void Dump() const {
|
|
|
|
|
if (m_py_obj)
|
|
|
|
|
_PyObject_Dump(m_py_obj);
|
|
|
|
|
else
|
|
|
|
|
puts("NULL");
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
void Dump(Stream &strm) const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
PyObject *get() const { return m_py_obj; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-14 16:59:32 +00:00
|
|
|
PyObject *release() {
|
|
|
|
|
PyObject *result = m_py_obj;
|
|
|
|
|
m_py_obj = nullptr;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-17 22:22:09 +00:00
|
|
|
PythonObject &operator=(PythonObject other) {
|
2019-10-08 17:56:18 +00:00
|
|
|
Reset();
|
2019-10-17 22:22:09 +00:00
|
|
|
m_py_obj = std::exchange(other.m_py_obj, nullptr);
|
2019-10-08 17:56:18 +00:00
|
|
|
return *this;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-11 17:59:49 +00:00
|
|
|
PyObjectType GetObjectType() const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-11 17:59:49 +00:00
|
|
|
PythonString Repr() const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-11 17:59:49 +00:00
|
|
|
PythonString Str() const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-12 17:01:48 +00:00
|
|
|
static PythonObject ResolveNameWithDictionary(llvm::StringRef name,
|
|
|
|
|
const PythonDictionary &dict);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-12 16:23:16 +00:00
|
|
|
template <typename T>
|
2015-11-12 17:01:48 +00:00
|
|
|
static T ResolveNameWithDictionary(llvm::StringRef name,
|
|
|
|
|
const PythonDictionary &dict) {
|
2015-11-12 16:23:16 +00:00
|
|
|
return ResolveNameWithDictionary(name, dict).AsType<T>();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-11 17:59:49 +00:00
|
|
|
PythonObject ResolveName(llvm::StringRef name) const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-12 16:23:16 +00:00
|
|
|
template <typename T> T ResolveName(llvm::StringRef name) const {
|
|
|
|
|
return ResolveName(name).AsType<T>();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-15 19:35:48 +00:00
|
|
|
bool HasAttribute(llvm::StringRef attribute) const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-16 17:51:49 +00:00
|
|
|
PythonObject GetAttributeValue(llvm::StringRef attribute) const;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
bool IsNone() const { return m_py_obj == Py_None; }
|
|
|
|
|
|
|
|
|
|
bool IsValid() const { return m_py_obj != nullptr; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
bool IsAllocated() const { return IsValid() && !IsNone(); }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
explicit operator bool() const { return IsValid() && !IsNone(); }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-16 17:51:49 +00:00
|
|
|
template <typename T> T AsType() const {
|
|
|
|
|
if (!T::Check(m_py_obj))
|
|
|
|
|
return T();
|
|
|
|
|
return T(PyRefType::Borrowed, m_py_obj);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-11 17:59:49 +00:00
|
|
|
StructuredData::ObjectSP CreateStructuredObject() const;
|
2012-08-24 05:45:15 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
public:
|
|
|
|
|
template <typename... T>
|
|
|
|
|
llvm::Expected<PythonObject> CallMethod(const char *name,
|
|
|
|
|
const T &... t) const {
|
|
|
|
|
const char format[] = {'(', PythonFormat<T>::format..., ')', 0};
|
|
|
|
|
PyObject *obj =
|
2019-10-17 22:22:06 +00:00
|
|
|
PyObject_CallMethod(m_py_obj, py2_const_cast(name),
|
|
|
|
|
py2_const_cast(format), PythonFormat<T>::get(t)...);
|
|
|
|
|
if (!obj)
|
|
|
|
|
return exception();
|
|
|
|
|
return python::Take<PythonObject>(obj);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <typename... T>
|
|
|
|
|
llvm::Expected<PythonObject> Call(const T &... t) const {
|
|
|
|
|
const char format[] = {'(', PythonFormat<T>::format..., ')', 0};
|
|
|
|
|
PyObject *obj = PyObject_CallFunction(m_py_obj, py2_const_cast(format),
|
|
|
|
|
PythonFormat<T>::get(t)...);
|
2019-10-08 17:56:18 +00:00
|
|
|
if (!obj)
|
|
|
|
|
return exception();
|
|
|
|
|
return python::Take<PythonObject>(obj);
|
|
|
|
|
}
|
|
|
|
|
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
llvm::Expected<PythonObject> GetAttribute(const llvm::Twine &name) const {
|
2019-10-08 17:56:18 +00:00
|
|
|
if (!m_py_obj)
|
|
|
|
|
return nullDeref();
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
PyObject *obj = PyObject_GetAttrString(m_py_obj, NullTerminated(name));
|
2019-10-08 17:56:18 +00:00
|
|
|
if (!obj)
|
|
|
|
|
return exception();
|
|
|
|
|
return python::Take<PythonObject>(obj);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llvm::Expected<bool> IsTrue() {
|
|
|
|
|
if (!m_py_obj)
|
|
|
|
|
return nullDeref();
|
|
|
|
|
int r = PyObject_IsTrue(m_py_obj);
|
|
|
|
|
if (r < 0)
|
|
|
|
|
return exception();
|
|
|
|
|
return !!r;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llvm::Expected<long long> AsLongLong() {
|
|
|
|
|
if (!m_py_obj)
|
|
|
|
|
return nullDeref();
|
|
|
|
|
assert(!PyErr_Occurred());
|
|
|
|
|
long long r = PyLong_AsLongLong(m_py_obj);
|
|
|
|
|
if (PyErr_Occurred())
|
|
|
|
|
return exception();
|
|
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-21 16:53:47 -07:00
|
|
|
llvm::Expected<long long> AsUnsignedLongLong() {
|
|
|
|
|
if (!m_py_obj)
|
|
|
|
|
return nullDeref();
|
|
|
|
|
assert(!PyErr_Occurred());
|
|
|
|
|
long long r = PyLong_AsUnsignedLongLong(m_py_obj);
|
|
|
|
|
if (PyErr_Occurred())
|
|
|
|
|
return exception();
|
|
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llvm::Expected<unsigned long long> AsModuloUnsignedLongLong() const {
|
|
|
|
|
// wraps on overflow, instead of raising an error.
|
|
|
|
|
if (!m_py_obj)
|
|
|
|
|
return nullDeref();
|
|
|
|
|
assert(!PyErr_Occurred());
|
|
|
|
|
unsigned long long r = PyLong_AsUnsignedLongLongMask(m_py_obj);
|
|
|
|
|
if (PyErr_Occurred())
|
|
|
|
|
return exception();
|
|
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
llvm::Expected<bool> IsInstance(const PythonObject &cls) {
|
|
|
|
|
if (!m_py_obj || !cls.IsValid())
|
|
|
|
|
return nullDeref();
|
|
|
|
|
int r = PyObject_IsInstance(m_py_obj, cls.get());
|
|
|
|
|
if (r < 0)
|
|
|
|
|
return exception();
|
|
|
|
|
return !!r;
|
|
|
|
|
}
|
|
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
protected:
|
|
|
|
|
PyObject *m_py_obj;
|
|
|
|
|
};
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
|
|
|
|
|
// This is why C++ needs monads.
|
|
|
|
|
template <typename T> llvm::Expected<T> As(llvm::Expected<PythonObject> &&obj) {
|
|
|
|
|
if (!obj)
|
|
|
|
|
return obj.takeError();
|
|
|
|
|
if (!T::Check(obj.get().get()))
|
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
|
"type error");
|
|
|
|
|
return T(PyRefType::Borrowed, std::move(obj.get().get()));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template <> llvm::Expected<bool> As<bool>(llvm::Expected<PythonObject> &&obj);
|
|
|
|
|
|
|
|
|
|
template <>
|
|
|
|
|
llvm::Expected<long long> As<long long>(llvm::Expected<PythonObject> &&obj);
|
|
|
|
|
|
2020-04-21 16:53:47 -07:00
|
|
|
template <>
|
|
|
|
|
llvm::Expected<unsigned long long>
|
|
|
|
|
As<unsigned long long>(llvm::Expected<PythonObject> &&obj);
|
|
|
|
|
|
2019-10-17 22:22:06 +00:00
|
|
|
template <>
|
|
|
|
|
llvm::Expected<std::string> As<std::string>(llvm::Expected<PythonObject> &&obj);
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
template <class T> class TypedPythonObject : public PythonObject {
|
2016-01-11 22:16:12 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
// override to perform implicit type conversions on Reset
|
|
|
|
|
// This can be eliminated once we drop python 2 support.
|
|
|
|
|
static void Convert(PyRefType &type, PyObject *&py_obj) {}
|
2016-01-11 22:16:12 +00:00
|
|
|
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
TypedPythonObject(PyRefType type, PyObject *py_obj) {
|
2019-10-15 17:12:49 +00:00
|
|
|
if (!py_obj)
|
|
|
|
|
return;
|
|
|
|
|
T::Convert(type, py_obj);
|
|
|
|
|
if (T::Check(py_obj))
|
2019-10-22 02:32:37 +00:00
|
|
|
PythonObject::operator=(PythonObject(type, py_obj));
|
2019-10-15 17:12:49 +00:00
|
|
|
else if (type == PyRefType::Owned)
|
|
|
|
|
Py_DECREF(py_obj);
|
|
|
|
|
}
|
2016-01-11 22:16:12 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
TypedPythonObject() {}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class PythonBytes : public TypedPythonObject<PythonBytes> {
|
|
|
|
|
public:
|
|
|
|
|
using TypedPythonObject::TypedPythonObject;
|
|
|
|
|
explicit PythonBytes(llvm::ArrayRef<uint8_t> bytes);
|
|
|
|
|
PythonBytes(const uint8_t *bytes, size_t length);
|
2016-01-11 22:16:12 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
2016-01-11 22:16:12 +00:00
|
|
|
|
|
|
|
|
llvm::ArrayRef<uint8_t> GetBytes() const;
|
|
|
|
|
|
|
|
|
|
size_t GetSize() const;
|
|
|
|
|
|
|
|
|
|
void SetBytes(llvm::ArrayRef<uint8_t> stringbytes);
|
|
|
|
|
|
|
|
|
|
StructuredData::StringSP CreateStructuredString() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonByteArray : public TypedPythonObject<PythonByteArray> {
|
2016-01-25 23:21:09 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2016-01-25 23:21:09 +00:00
|
|
|
explicit PythonByteArray(llvm::ArrayRef<uint8_t> bytes);
|
|
|
|
|
PythonByteArray(const uint8_t *bytes, size_t length);
|
|
|
|
|
PythonByteArray(const PythonBytes &object);
|
|
|
|
|
|
|
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
|
|
|
|
|
llvm::ArrayRef<uint8_t> GetBytes() const;
|
|
|
|
|
|
|
|
|
|
size_t GetSize() const;
|
|
|
|
|
|
|
|
|
|
void SetBytes(llvm::ArrayRef<uint8_t> stringbytes);
|
|
|
|
|
|
|
|
|
|
StructuredData::StringSP CreateStructuredString() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonString : public TypedPythonObject<PythonString> {
|
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
2015-10-13 18:16:15 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2019-10-08 17:56:18 +00:00
|
|
|
static llvm::Expected<PythonString> FromUTF8(llvm::StringRef string);
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
PythonString() : TypedPythonObject() {} // MSVC requires this for some reason
|
2015-10-24 01:08:35 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
explicit PythonString(llvm::StringRef string); // safe, null on error
|
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
2015-10-09 19:45:41 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
2019-10-15 17:12:49 +00:00
|
|
|
static void Convert(PyRefType &type, PyObject *&py_obj);
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
llvm::StringRef GetString() const; // safe, empty string on error
|
|
|
|
|
|
|
|
|
|
llvm::Expected<llvm::StringRef> AsUTF8() const;
|
2015-03-17 20:04:04 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
size_t GetSize() const;
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
void SetString(llvm::StringRef string); // safe, null on error
|
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
2015-10-09 19:45:41 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
StructuredData::StringSP CreateStructuredString() const;
|
|
|
|
|
};
|
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
2015-10-09 19:45:41 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonInteger : public TypedPythonObject<PythonInteger> {
|
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
2015-10-13 18:16:15 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2015-10-24 01:08:35 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
PythonInteger() : TypedPythonObject() {} // MSVC requires this for some reason
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
explicit PythonInteger(int64_t value);
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
static void Convert(PyRefType &type, PyObject *&py_obj);
|
2015-03-17 20:04:04 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
void SetInteger(int64_t value);
|
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
2015-10-09 19:45:41 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
StructuredData::IntegerSP CreateStructuredInteger() const;
|
|
|
|
|
};
|
2015-03-17 20:04:04 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonBoolean : public TypedPythonObject<PythonBoolean> {
|
2019-02-16 18:39:14 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2019-02-16 18:39:14 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
explicit PythonBoolean(bool value);
|
2019-02-16 18:39:14 +00:00
|
|
|
|
|
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
|
|
|
|
|
bool GetValue() const;
|
|
|
|
|
|
|
|
|
|
void SetValue(bool value);
|
|
|
|
|
|
|
|
|
|
StructuredData::BooleanSP CreateStructuredBoolean() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonList : public TypedPythonObject<PythonList> {
|
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
2015-10-13 18:16:15 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
|
|
|
|
|
|
|
|
|
PythonList() : TypedPythonObject() {} // MSVC requires this for some reason
|
|
|
|
|
|
2015-10-14 16:59:44 +00:00
|
|
|
explicit PythonList(PyInitialValue value);
|
|
|
|
|
explicit PythonList(int list_size);
|
2015-03-17 20:04:04 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
2012-08-24 01:42:50 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
uint32_t GetSize() const;
|
|
|
|
|
|
|
|
|
|
PythonObject GetItemAtIndex(uint32_t index) const;
|
2014-01-27 23:43:24 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
void SetItemAtIndex(uint32_t index, const PythonObject &object);
|
2015-03-17 20:04:04 +00:00
|
|
|
|
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
2015-10-13 18:16:15 +00:00
|
|
|
void AppendItem(const PythonObject &object);
|
|
|
|
|
|
|
|
|
|
StructuredData::ArraySP CreateStructuredArray() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonTuple : public TypedPythonObject<PythonTuple> {
|
2015-11-11 19:42:27 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
|
|
|
|
|
2015-11-11 19:42:27 +00:00
|
|
|
explicit PythonTuple(PyInitialValue value);
|
|
|
|
|
explicit PythonTuple(int tuple_size);
|
|
|
|
|
PythonTuple(std::initializer_list<PythonObject> objects);
|
|
|
|
|
PythonTuple(std::initializer_list<PyObject *> objects);
|
|
|
|
|
|
|
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
|
|
|
|
|
uint32_t GetSize() const;
|
|
|
|
|
|
|
|
|
|
PythonObject GetItemAtIndex(uint32_t index) const;
|
|
|
|
|
|
|
|
|
|
void SetItemAtIndex(uint32_t index, const PythonObject &object);
|
|
|
|
|
|
|
|
|
|
StructuredData::ArraySP CreateStructuredArray() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonDictionary : public TypedPythonObject<PythonDictionary> {
|
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
2015-10-13 18:16:15 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2015-10-24 01:08:35 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
PythonDictionary() : TypedPythonObject() {} // MSVC requires this for some reason
|
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
2015-10-13 18:16:15 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
explicit PythonDictionary(PyInitialValue value);
|
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
2015-10-13 18:16:15 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
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
2015-10-13 18:16:15 +00:00
|
|
|
|
|
|
|
|
uint32_t GetSize() const;
|
|
|
|
|
|
|
|
|
|
PythonList GetKeys() const;
|
|
|
|
|
|
2019-10-17 22:22:06 +00:00
|
|
|
PythonObject GetItemForKey(const PythonObject &key) const; // DEPRECATED
|
|
|
|
|
void SetItemForKey(const PythonObject &key,
|
|
|
|
|
const PythonObject &value); // DEPRECATED
|
|
|
|
|
|
|
|
|
|
llvm::Expected<PythonObject> GetItem(const PythonObject &key) const;
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
llvm::Expected<PythonObject> GetItem(const llvm::Twine &key) const;
|
2019-10-17 22:22:06 +00:00
|
|
|
llvm::Error SetItem(const PythonObject &key, const PythonObject &value) const;
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
llvm::Error SetItem(const llvm::Twine &key, const PythonObject &value) const;
|
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
2015-10-13 18:16:15 +00:00
|
|
|
|
|
|
|
|
StructuredData::DictionarySP CreateStructuredDictionary() const;
|
|
|
|
|
};
|
2015-10-14 16:59:44 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonModule : public TypedPythonObject<PythonModule> {
|
2015-11-11 17:59:49 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2015-11-11 17:59:49 +00:00
|
|
|
|
|
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
|
2015-11-11 19:42:27 +00:00
|
|
|
static PythonModule BuiltinsModule();
|
|
|
|
|
|
|
|
|
|
static PythonModule MainModule();
|
|
|
|
|
|
|
|
|
|
static PythonModule AddModule(llvm::StringRef module);
|
2015-11-11 17:59:49 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
// safe, returns invalid on error;
|
|
|
|
|
static PythonModule ImportModule(llvm::StringRef name) {
|
2020-01-28 20:23:46 +01:00
|
|
|
std::string s = std::string(name);
|
2019-10-08 17:56:18 +00:00
|
|
|
auto mod = Import(s.c_str());
|
|
|
|
|
if (!mod) {
|
|
|
|
|
llvm::consumeError(mod.takeError());
|
|
|
|
|
return PythonModule();
|
|
|
|
|
}
|
|
|
|
|
return std::move(mod.get());
|
|
|
|
|
}
|
|
|
|
|
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
static llvm::Expected<PythonModule> Import(const llvm::Twine &name);
|
2019-10-08 17:56:18 +00:00
|
|
|
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
llvm::Expected<PythonObject> Get(const llvm::Twine &name);
|
2015-11-13 21:28:45 +00:00
|
|
|
|
2015-11-11 17:59:49 +00:00
|
|
|
PythonDictionary GetDictionary() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonCallable : public TypedPythonObject<PythonCallable> {
|
2015-11-11 19:42:27 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
|
|
|
|
|
2015-11-12 16:23:16 +00:00
|
|
|
struct ArgInfo {
|
2019-10-19 07:05:33 +00:00
|
|
|
/* the largest number of positional arguments this callable
|
|
|
|
|
* can accept, or UNBOUNDED, ie UINT_MAX if it's a varargs
|
|
|
|
|
* function and can accept an arbitrary number */
|
|
|
|
|
unsigned max_positional_args;
|
|
|
|
|
static constexpr unsigned UNBOUNDED = UINT_MAX; // FIXME c++17 inline
|
2015-11-12 16:23:16 +00:00
|
|
|
};
|
|
|
|
|
|
2015-11-11 19:42:27 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
|
2019-10-17 22:22:06 +00:00
|
|
|
llvm::Expected<ArgInfo> GetArgInfo() const;
|
|
|
|
|
|
2015-11-12 16:23:16 +00:00
|
|
|
PythonObject operator()();
|
2015-11-11 19:42:27 +00:00
|
|
|
|
|
|
|
|
PythonObject operator()(std::initializer_list<PyObject *> args);
|
|
|
|
|
|
|
|
|
|
PythonObject operator()(std::initializer_list<PythonObject> args);
|
2015-11-12 16:23:16 +00:00
|
|
|
|
|
|
|
|
template <typename Arg, typename... Args>
|
|
|
|
|
PythonObject operator()(const Arg &arg, Args... args) {
|
|
|
|
|
return operator()({arg, args...});
|
|
|
|
|
}
|
2015-11-11 19:42:27 +00:00
|
|
|
};
|
|
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
class PythonFile : public TypedPythonObject<PythonFile> {
|
2016-09-06 20:57:50 +00:00
|
|
|
public:
|
2019-10-15 17:12:49 +00:00
|
|
|
using TypedPythonObject::TypedPythonObject;
|
2015-11-11 19:42:27 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
PythonFile() : TypedPythonObject() {} // MSVC requires this for some reason
|
2015-10-24 01:08:35 +00:00
|
|
|
|
2015-10-15 19:35:48 +00:00
|
|
|
static bool Check(PyObject *py_obj);
|
|
|
|
|
|
2019-10-15 16:46:27 +00:00
|
|
|
static llvm::Expected<PythonFile> FromFile(File &file,
|
|
|
|
|
const char *mode = nullptr);
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
llvm::Expected<lldb::FileSP> ConvertToFile(bool borrowed = false);
|
|
|
|
|
llvm::Expected<lldb::FileSP>
|
|
|
|
|
ConvertToFileForcingUseOfScriptingIOMethods(bool borrowed = false);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class PythonException : public llvm::ErrorInfo<PythonException> {
|
|
|
|
|
private:
|
|
|
|
|
PyObject *m_exception_type, *m_exception, *m_traceback;
|
|
|
|
|
PyObject *m_repr_bytes;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
static char ID;
|
|
|
|
|
const char *toCString() const;
|
|
|
|
|
PythonException(const char *caller = nullptr);
|
|
|
|
|
void Restore();
|
|
|
|
|
~PythonException();
|
|
|
|
|
void log(llvm::raw_ostream &OS) const override;
|
|
|
|
|
std::error_code convertToErrorCode() const override;
|
2019-10-22 02:32:37 +00:00
|
|
|
bool Matches(PyObject *exc) const;
|
|
|
|
|
std::string ReadBacktrace() const;
|
2015-10-15 19:35:48 +00:00
|
|
|
};
|
|
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
// This extracts the underlying T out of an Expected<T> and returns it.
|
|
|
|
|
// If the Expected is an Error instead of a T, that error will be converted
|
|
|
|
|
// into a python exception, and this will return a default-constructed T.
|
|
|
|
|
//
|
|
|
|
|
// This is appropriate for use right at the boundary of python calling into
|
|
|
|
|
// C++, such as in a SWIG typemap. In such a context you should simply
|
|
|
|
|
// check if the returned T is valid, and if it is, return a NULL back
|
|
|
|
|
// to python. This will result in the Error being raised as an exception
|
|
|
|
|
// from python code's point of view.
|
|
|
|
|
//
|
|
|
|
|
// For example:
|
|
|
|
|
// ```
|
|
|
|
|
// Expected<Foo *> efoop = some_cpp_function();
|
|
|
|
|
// Foo *foop = unwrapOrSetPythonException(efoop);
|
|
|
|
|
// if (!foop)
|
|
|
|
|
// return NULL;
|
|
|
|
|
// do_something(*foop);
|
|
|
|
|
//
|
|
|
|
|
// If the Error returned was itself created because a python exception was
|
|
|
|
|
// raised when C++ code called into python, then the original exception
|
|
|
|
|
// will be restored. Otherwise a simple string exception will be raised.
|
|
|
|
|
template <typename T> T unwrapOrSetPythonException(llvm::Expected<T> expected) {
|
|
|
|
|
if (expected)
|
|
|
|
|
return expected.get();
|
|
|
|
|
llvm::handleAllErrors(
|
|
|
|
|
expected.takeError(), [](PythonException &E) { E.Restore(); },
|
|
|
|
|
[](const llvm::ErrorInfoBase &E) {
|
|
|
|
|
PyErr_SetString(PyExc_Exception, E.message().c_str());
|
|
|
|
|
});
|
|
|
|
|
return T();
|
|
|
|
|
}
|
|
|
|
|
|
eliminate nontrivial Reset(...) from TypedPythonObject
Summary:
This deletes `Reset(...)`, except for the no-argument form `Reset()`
from `TypedPythonObject`, and therefore from `PythonString`, `PythonList`,
etc.
It updates the various callers to use assignment, `As<>`, `Take<>`,
and `Retain<>`, as appropriate.
followon to https://reviews.llvm.org/D69080
Reviewers: JDevlieghere, clayborg, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69133
llvm-svn: 375350
2019-10-19 18:43:49 +00:00
|
|
|
// This is only here to help incrementally migrate old, exception-unsafe
|
|
|
|
|
// code.
|
|
|
|
|
template <typename T> T unwrapIgnoringErrors(llvm::Expected<T> expected) {
|
|
|
|
|
if (expected)
|
|
|
|
|
return std::move(expected.get());
|
|
|
|
|
llvm::consumeError(expected.takeError());
|
|
|
|
|
return T();
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-22 02:32:37 +00:00
|
|
|
llvm::Expected<PythonObject> runStringOneLine(const llvm::Twine &string,
|
|
|
|
|
const PythonDictionary &globals,
|
|
|
|
|
const PythonDictionary &locals);
|
|
|
|
|
|
|
|
|
|
llvm::Expected<PythonObject> runStringMultiLine(const llvm::Twine &string,
|
|
|
|
|
const PythonDictionary &globals,
|
|
|
|
|
const PythonDictionary &locals);
|
|
|
|
|
|
|
|
|
|
// Sometimes the best way to interact with a python interpreter is
|
|
|
|
|
// to run some python code. You construct a PythonScript with
|
|
|
|
|
// script string. The script assigns some function to `_function_`
|
|
|
|
|
// and you get a C++ callable object that calls the python function.
|
|
|
|
|
//
|
|
|
|
|
// Example:
|
|
|
|
|
//
|
|
|
|
|
// const char script[] = R"(
|
|
|
|
|
// def main(x, y):
|
|
|
|
|
// ....
|
|
|
|
|
// )";
|
|
|
|
|
//
|
|
|
|
|
// Expected<PythonObject> cpp_foo_wrapper(PythonObject x, PythonObject y) {
|
|
|
|
|
// // no need to synchronize access to this global, we already have the GIL
|
|
|
|
|
// static PythonScript foo(script)
|
|
|
|
|
// return foo(x, y);
|
|
|
|
|
// }
|
|
|
|
|
class PythonScript {
|
|
|
|
|
const char *script;
|
|
|
|
|
PythonCallable function;
|
|
|
|
|
|
|
|
|
|
llvm::Error Init();
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
PythonScript(const char *script) : script(script), function() {}
|
|
|
|
|
|
|
|
|
|
template <typename... Args>
|
|
|
|
|
llvm::Expected<PythonObject> operator()(Args &&... args) {
|
|
|
|
|
if (llvm::Error error = Init())
|
|
|
|
|
return std::move(error);
|
|
|
|
|
return function.Call(std::forward<Args>(args)...);
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace python
|
2012-08-23 22:02:23 +00:00
|
|
|
} // namespace lldb_private
|
|
|
|
|
|
2015-11-13 17:27:20 +00:00
|
|
|
#endif
|
2018-06-21 17:36:32 +00:00
|
|
|
|
|
|
|
|
#endif // LLDB_PLUGINS_SCRIPTINTERPRETER_PYTHON_PYTHONDATAOBJECTS_H
|