| Age | Commit message (Collapse) | Author |
|---|
|
This is a reland of #129135 (by dingxiangfei2009) with Vladislav
(dzhidzhoev) fix on top.
Fixes #92603
|
|
We missed a handful of uses of the Python private API in the SWIG
typemaps because they are included before we include the Python header
that defines Py_LIMITED_API.
This fixes that and guards the last private use on whether or not you're
targeting the limited API. Unfortunately there doesn't appear to be an
alternative, so we have to resort to being slightly less defensive.
|
|
|
|
Reverts llvm/llvm-project#129135 due to buildbot test failures.
Definitely caused remote Linux to Windows failures
(https://lab.llvm.org/buildbot/#/builders/197/builds/2712), may be the
cause of Windows on Arm failures
https://lab.llvm.org/buildbot/#/builders/141/builds/6744.
|
|
Fix #92603
This replaces #113066. I finally came back to this issue and it seems
that this approach is still very promising.
As requested, I have added a short explanation as to why CPython module
should be moved into a submodule.
cc @JDevlieghere who reviewed on the previous PR earlier.
|
|
This reverts 3 commit:
- f0731d5b61ba798e6d5a63a92d9228010e5a3b50.
- 8e0a087571a31057bb98939e3ada73227bed83c7.
- f2f5d6fb8d53bc4bd93a3d4e110134ed017b636f.
This changes were introduced to silence the warnings that are printed
when generating the lldb module documentation for the website but it
changed the python bindings and causes test failures on the macos bot:
https://green.lab.llvm.org/green/job/lldb-cmake/59438/
We will have to consider other options to silence these warnings.
|
|
This reverts commit 18f1c1ace7a6099f3e8e56cf4b81aa0f64a7dd23 and fix the
build failure issues introduced because of the `STRING_EXTENSION_OUTSIDE`
swig macros.
Differential Revision: https://reviews.llvm.org/D159017
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This reverts commit 498b59e01133bed16c72dd939a9daa8ae1f359e4 since it
introduces a build failure:
https://lab.llvm.org/buildbot/#/builders/68/builds/58995
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This patch does various things to silence the warnings that show up when
generating the website documentation.
First, this patch adds the missing definition for special member methods
in every SBAPI class. If the class cannot implement one of the special
member method, we just define it as a null operation (pass).
This should fix the following warnings:
```
WARNING: missing attribute __int__ in object lldb.SB*
WARNING: missing attribute __len__ in object lldb.SB*
WARNING: missing attribute __hex__ in object lldb.SB*
WARNING: missing attribute __oct__ in object lldb.SB*
WARNING: missing attribute __iter__ in object lldb.SB*
```
Then, it un-skips the various `static` methods that we didn't generate
the methods for, since it's not necessary thanks to the automod-api module.
Finally, this comments out the `_static` directory in the sphinx config,
since we don't need it anymore.
Differential Revision: https://reviews.llvm.org/D159017
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
SWIG 4 was released in 2019 and has been the de-facto standard for a
while now. All bots are running SWIG 4.0 or later.
This was motivated by #64279 which discovered that 662548c broke the
LLDB build with SWIG 3 on Windows.
Differential revision: https://reviews.llvm.org/D156804
|
|
With lldb (& llvm) requiring Python 3.6+, use of the `six` module can be removed.
Differential Revision: https://reviews.llvm.org/D131304
|
|
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.
|
|
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
|
|
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
|
|
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).
|
|
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
|
|
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
|
