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.
|
|
|
|
|
//
|
|
|
|
|
// * Elimintate Reset(), and make all non-default constructors private.
|
|
|
|
|
// 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
|
|
|
|
2018-06-21 17:36:32 +00:00
|
|
|
#ifndef LLDB_DISABLE_PYTHON
|
|
|
|
|
|
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 {
|
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
|
|
|
namespace python {
|
|
|
|
|
|
|
|
|
|
// 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());
|
|
|
|
|
return std::move(thing);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// 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());
|
|
|
|
|
return std::move(thing);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // namespace python
|
|
|
|
|
|
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; }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
PythonObject(PyRefType type, PyObject *py_obj) : m_py_obj(nullptr) {
|
|
|
|
|
Reset(type, py_obj);
|
|
|
|
|
}
|
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
|
|
|
PythonObject(const PythonObject &rhs) : m_py_obj(nullptr) { Reset(rhs); }
|
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 Reset(const PythonObject &rhs) {
|
2015-10-14 16:59:32 +00:00
|
|
|
if (!rhs.IsValid())
|
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
|
|
|
Reset();
|
|
|
|
|
else
|
|
|
|
|
Reset(PyRefType::Borrowed, rhs.m_py_obj);
|
|
|
|
|
}
|
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
|
|
|
// PythonObject is implicitly convertible to PyObject *, which will call the
|
|
|
|
|
// wrong overload. We want to explicitly disallow this, since a PyObject
|
|
|
|
|
// *always* owns its reference. Therefore the overload which takes a
|
|
|
|
|
// PyRefType doesn't make sense, and the copy constructor should be used.
|
|
|
|
|
void Reset(PyRefType type, const PythonObject &ref) = delete;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
void Reset(PyRefType type, 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
|
|
|
if (py_obj == m_py_obj)
|
|
|
|
|
return;
|
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
|
|
|
if (Py_IsInitialized())
|
|
|
|
|
Py_XDECREF(m_py_obj);
|
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
|
|
|
m_py_obj = py_obj;
|
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
|
|
|
// 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.
|
2019-10-08 17:56:18 +00:00
|
|
|
if (m_py_obj && Py_IsInitialized() && type == PyRefType::Borrowed)
|
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
|
|
|
Py_XINCREF(m_py_obj);
|
|
|
|
|
}
|
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
|
|
|
|
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
|
|
|
PythonObject &operator=(const PythonObject &other) {
|
|
|
|
|
Reset(PyRefType::Borrowed, other.get());
|
|
|
|
|
return *this;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-08 17:56:18 +00:00
|
|
|
void Reset(PythonObject &&other) {
|
|
|
|
|
Reset();
|
|
|
|
|
m_py_obj = other.m_py_obj;
|
|
|
|
|
other.m_py_obj = nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PythonObject &operator=(PythonObject &&other) {
|
|
|
|
|
Reset(std::move(other));
|
|
|
|
|
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
|
|
|
protected:
|
|
|
|
|
static llvm::Error nullDeref() {
|
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
|
"A NULL PyObject* was dereferenced");
|
|
|
|
|
}
|
|
|
|
|
static llvm::Error exception(const char *s = nullptr) {
|
|
|
|
|
return llvm::make_error<PythonException>(s);
|
|
|
|
|
}
|
2019-10-17 22:22:06 +00:00
|
|
|
static llvm::Error keyError() {
|
|
|
|
|
return llvm::createStringError(llvm::inconvertibleErrorCode(),
|
|
|
|
|
"key not in dict");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#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.
|
|
|
|
|
static char *py2_const_cast(const char *s) { return const_cast<char *>(s); }
|
|
|
|
|
#else
|
|
|
|
|
static const char *py2_const_cast(const char *s) { return s; }
|
|
|
|
|
#endif
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
llvm::Expected<PythonObject> GetAttribute(const char *name) const {
|
|
|
|
|
if (!m_py_obj)
|
|
|
|
|
return nullDeref();
|
|
|
|
|
PyObject *obj = PyObject_GetAttrString(m_py_obj, name);
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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
|
|
|
namespace python {
|
|
|
|
|
|
|
|
|
|
// 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);
|
|
|
|
|
|
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
|
|
|
} // namespace python
|
|
|
|
|
|
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
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
using PythonObject::Reset;
|
2016-01-11 22:16:12 +00:00
|
|
|
|
2019-10-15 17:12:49 +00:00
|
|
|
void Reset(PyRefType type, PyObject *py_obj) {
|
|
|
|
|
Reset();
|
|
|
|
|
if (!py_obj)
|
|
|
|
|
return;
|
|
|
|
|
T::Convert(type, py_obj);
|
|
|
|
|
if (T::Check(py_obj))
|
|
|
|
|
PythonObject::Reset(type, py_obj);
|
|
|
|
|
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(PyRefType type, PyObject *py_obj) { Reset(type, py_obj); }
|
|
|
|
|
|
|
|
|
|
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
|
|
|
int64_t GetInteger() 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
|
|
|
|
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;
|
|
|
|
|
llvm::Expected<PythonObject> GetItem(const char *key) const;
|
|
|
|
|
llvm::Error SetItem(const PythonObject &key, const PythonObject &value) const;
|
|
|
|
|
llvm::Error SetItem(const char *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) {
|
|
|
|
|
std::string s = name;
|
|
|
|
|
auto mod = Import(s.c_str());
|
|
|
|
|
if (!mod) {
|
|
|
|
|
llvm::consumeError(mod.takeError());
|
|
|
|
|
return PythonModule();
|
|
|
|
|
}
|
|
|
|
|
return std::move(mod.get());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static llvm::Expected<PythonModule> Import(const char *name);
|
|
|
|
|
|
|
|
|
|
llvm::Expected<PythonObject> Get(const char *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-17 22:22:06 +00:00
|
|
|
/* the number of positional arguments, including optional ones,
|
|
|
|
|
* and excluding varargs. If this is a bound method, then the
|
|
|
|
|
* count will still include a +1 for self.
|
|
|
|
|
*
|
|
|
|
|
* FIXME. That's crazy. This should be replaced with
|
|
|
|
|
* an accurate min and max for positional args.
|
|
|
|
|
*/
|
|
|
|
|
int count;
|
|
|
|
|
/* does the callable have positional varargs? */
|
|
|
|
|
bool has_varargs : 1; // FIXME delete this
|
|
|
|
|
/* is the callable a bound method written in python? */
|
|
|
|
|
bool is_bound_method : 1; // FIXME delete this
|
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;
|
|
|
|
|
|
|
|
|
|
llvm::Expected<ArgInfo> GetInitArgInfo() const;
|
|
|
|
|
|
|
|
|
|
ArgInfo GetNumArguments() const; // DEPRECATED
|
2019-10-15 16:46:27 +00:00
|
|
|
|
2019-10-03 22:50:18 +00:00
|
|
|
// If the callable is a Py_Class, then find the number of arguments
|
|
|
|
|
// of the __init__ method.
|
2019-10-17 22:22:06 +00:00
|
|
|
ArgInfo GetNumInitArguments() const; // DEPRECATED
|
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;
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
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
|