[lldb] Remove lldbconfig module

The lldbconfig module was necessary to run the LLDB test suite against a
reproducer. Since this functionality has been removed, the module is no
longer necessary.

[lldb] Remove 'extern "C"' from the lldb-swig-python interface

The LLDBSWIGPython functions had (at least) two problems:
- There wasn't a single source of truth (a header file) for the
prototypes

[lldb] Remove 'extern "C"' from the lldb-swig-python interface

The LLDBSWIGPython functions had (at least) two problems:
- There wasn't a single source of truth (a header file) for the
prototypes of these functions. This meant that subtle differences
in copies of function declarations could go by undetected. And
not-so-subtle differences would result in strange runtime failures.
- All of the declarations had to have an extern "C" interface, because
the function definitions were being placed inside and extert "C" block
generated by swig.

This patch fixes both problems by moving the function definitions to the
%header block of the swig files. This block is not surrounded by extern
"C", and seems more appropriate anyway, as swig docs say it is meant for
"user-defined support code" (whereas the previous %wrapper code was for
automatically-generated wrappers).

It also puts the declarations into the SWIGPythonBridge header file
(which seems to have been created for this purpose), and ensures it is
included by all code wishing to define or use these functions. This
means that any differences in the declaration become a compiler error
instead of a runtime failure.

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

show more ...

[lldb][docs] Add a doc page for enums and constants

Enums and constants are currently missing in the new LLDB Python API docs.

In theory we could just let them be autogenerated like the SB API clas

[lldb][docs] Add a doc page for enums and constants

Enums and constants are currently missing in the new LLDB Python API docs.

In theory we could just let them be autogenerated like the SB API classes, but sadly the generated documentation
suffers from a bunch of problems. Most of these problems come from the way SWIG is representing enums, which is
done by translating every single enum case into its own constant. This has a bunch of nasty effects:

* Because SWIG throws away the enum types, we can't actually reference the enum type itself in the API. Also because automodapi is impossible to script, this can't be fixed in post (at least without running like sed over the output files).
* The lack of enum types also causes that every enum *case* has its own full doc page. Having a full doc page that just shows a single enum case is pointless and it really slows down sphinx.
* There is no SWIG code for the enums, so there is also no place to write documentation strings for them. Also there is no support for copying the doxygen strings (which would be in the wrong format, but better than nothing) for enums (let alone our defines), so we can't really document all this code.
* Because the enum cases are just forwards to the native lldb module (which we mock), automodapi actually takes the `Mock` docstrings and adds it to every single enum case.

I don't see any way to solve this via automodapi or SWIG. The most reasonable way to solve this is IMHO to write a simple Clang tool
that just parses our enum/constant headers and emits an *.rst file that we check in. This way we can do all the LLDB-specific enum case and constant
grouping that we need to make a readable documentation page.

As we're without any real documentation until I get around to write that tool, I wrote a doc page for the enums/constants as a stop gap measure.
Most of this is done by just grepping our enum header and then manually cleaning up all the artifacts and copying the few doc strings we have.

Reviewed By: JDevlieghere

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

show more ...

[lldb][docs] Translate ASCII art to restructured text formatting

This translates most of the old ASCII art in our documentation to the
equivalent in restructured text (which the new version of the L

[lldb][docs] Translate ASCII art to restructured text formatting

This translates most of the old ASCII art in our documentation to the
equivalent in restructured text (which the new version of the LLDB docs
is using).

show more ...

[lldb] Fix relative imports and set the appropriate include dirs

After moving python.swig and lua.swig into their respective
subdirectories, the relative paths in these files were out of date. This

[lldb] Fix relative imports and set the appropriate include dirs

After moving python.swig and lua.swig into their respective
subdirectories, the relative paths in these files were out of date. This
fixes that and ensures the appropriate include paths are set in the SWIG
invocation.

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

show more ...

[lldb/CMake] Separate CMake code for Lua and Python (NFC)

Separate the CMake logic for Lua and Python to clearly distinguish
between code specific to either scripting language and the code shared
by

[lldb/CMake] Separate CMake code for Lua and Python (NFC)

Separate the CMake logic for Lua and Python to clearly distinguish
between code specific to either scripting language and the code shared
by both.

What this patch does is:

- Move Python specific code into the bindings/python subdirectory.
- Move the Lua specific code into the bindings/lua subdirectory.
- Add the _python suffix to Python specific functions/targets.
- Fix a dependency issue that would check the binding instead of
whether the scripting language is enabled.

Note that this patch also changes where the bindings are generated,
which might affect downstream projects that check them in.

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

show more ...