PythonObject::Dump isn't called and uses `_PyObject_Dump`, which isn't part of the stable API. Part of https://github.com/llvm/llvm-project/issues/151617.
Reimplment `PyRun_SimpleString` using the Python stable C API and the `RunString` helper. Part of https://github.com/llvm/llvm-project/issues/151617
Reimplement `PyRun_String` using `Py_CompileString` and` PyEval_EvalCode`, which are part of the stable C API. Part of #151617
Reverts https://github.com/llvm/llvm-project/pull/97273 since it broke the windows bot: https://lab.llvm.org/buildbot/#/builders/141/builds/1025/steps/4/logs/stdio
This patch tries to fix the following build failure on windows: https://lab.llvm.org/buildbot/#/builders/141/builds/1083 This started happening following 2914a4b88837, and it seems to be caused by some special `#include` ordering for the lldb-python header on Windows. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This allows you to specify options and arguments and their definitions and then have lldb handle the completions, help, etc. in the same way that lldb does for its parsed commands internally. This feature has some design considerations as well as the code, so I've also set up an RFC, but I did this one first and will put the RFC address in here once I've pushed it... Note, the lldb "ParsedCommand interface" doesn't actually do all the work that it should. For instance, saying the type of an option that has a completer doesn't automatically hook up the completer, and ditto for argument values. We also do almost no work to verify that the arguments match their definition, or do auto-completion for them. This patch allows you to make a command that's bug-for-bug compatible with built-in ones, but I didn't want to stall it on getting the auto-command checking to work all the way correctly. As an overall design note, my primary goal here was to make an interface that worked well in the script language. For that I needed, for instance, to have a property-based way to get all the option values that were specified. It was much more convenient to do that by making a fairly bare-bones C interface to define the options and arguments of a command, and set their values, and then wrap that in a Python class (installed along with the other bits of the lldb python module) which you can then derive from to make your new command. This approach will also make it easier to experiment. See the file test_commands.py in the test case for examples of how this works.
This patch enforces that every scripted object implements all the necessary abstract methods. Every scripted affordance language interface can implement a list of abstract methods name that checked when the object is instanciated. Since some scripting affordances implementations can be derived from template base classes, we can't check the object dictionary since it will contain the definition of the base class, so instead, this checks the scripting class dictionary. Previously, for the various python interfaces, we used `ABC.abstractmethod` decorators but this is too language specific and doesn't work for scripting affordances that are not derived from template base classes (i.e OperatingSystem, ScriptedThreadPlan, ...), so this patch provides generic/language-agnostic checks for every scripted affordance. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This reverts commit cc9ad72713405ef8f2468c7a714a137b4a3343ba since it breaks some tests upstream: https://lab.llvm.org/buildbot/#/builders/68/builds/63112 ******************** Failed Tests (4): lldb-api :: functionalities/gdb_remote_client/TestThreadSelectionBug.py lldb-api :: functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py lldb-api :: functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py lldb-api :: functionalities/postmortem/mach-core/TestMachCore.py
This patch enforces that every scripted object implements all the necessary abstract methods. Every scripted affordance language interface can implement a list of abstract methods name that checked when the object is instanciated. Since some scripting affordances implementations can be derived from template base classes, we can't check the object dictionary since it will contain the definition of the base class, so instead, this checks the scripting class dictionary. Previously, for the various python interfaces, we used `ABC.abstractmethod` decorators but this is too language specific and doesn't work for scripting affordances that are not derived from template base classes (i.e OperatingSystem, ScriptedThreadPlan, ...), so this patch provides generic/language-agnostic checks for every scripted affordance. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.
To do so, this patch changes the `ScriptedObject` struture that holds
the pointer to the script object as well as the originating script
interpreter language. It also exposes that to the SB API via a new class
called `SBScriptObject`.
This structure allows the debugger to parse the script object and
convert it to a StructuredData object. If the type is not compatible
with the StructuredData types, we will store its pointer in a
`StructuredData::Generic` object.
This patch also adds some SWIG typemaps that checks the input argument to
ensure it's either an SBStructuredData object, in which case it just
passes it throught, or a python object that is NOT another SB type, to
provide some guardrails for the user.
rdar://111467140
Differential Revision: https://reviews.llvm.org/D155161
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>