[lldb][Docs][NFC] Fix sphinx warnings/errors for LLDB docs

Ran `ninja docs-lldb-html` and made sure the docs are fixed.

Differential Revision: https://reviews.llvm.org/D136766
This commit is contained in:
Michael Buch 2022-10-26 14:40:34 +01:00
parent 14384c96df
commit 2a812bdc70
6 changed files with 18 additions and 17 deletions

View File

@ -137,8 +137,11 @@ public:
void void
Clear(); Clear();
%feature("docstring", "Check if the module is file backed. %feature("docstring", "
Check if the module is file backed.
@return @return
True, if the module is backed by an object file on disk. True, if the module is backed by an object file on disk.
False, if the module is backed by an object file in memory.") IsFileBacked; False, if the module is backed by an object file in memory.") IsFileBacked;
bool bool

View File

@ -947,7 +947,7 @@ public:
%feature("docstring", " %feature("docstring", "
Returns true if the module has been loaded in this `SBTarget`. Returns true if the module has been loaded in this `SBTarget`.
A module can be loaded either by the dynamic loader or by being manually A module can be loaded either by the dynamic loader or by being manually
added to the target (see `SBTarget.AddModule` and the `target module add` command). added to the target (see `SBTarget.AddModule` and the ``target module add`` command).
:rtype: bool :rtype: bool
") IsLoaded; ") IsLoaded;

View File

@ -229,7 +229,7 @@ public:
function returns ``0``. function returns ``0``.
* C++: Same as in C. * C++: Same as in C.
* Objective-C: Same as in C. For Objective-C classes this always returns * Objective-C: Same as in C. For Objective-C classes this always returns
`0`` as the actual size depends on runtime information. ``0`` as the actual size depends on runtime information.
") GetByteSize; ") GetByteSize;
uint64_t uint64_t
GetByteSize(); GetByteSize();
@ -506,7 +506,7 @@ public:
Language-specific behaviour: Language-specific behaviour:
* C: Returns a constant-size array `T[size]` for any non-void type. * C: Returns a constant-size array ``T[size]`` for any non-void type.
* C++: Same as in C. * C++: Same as in C.
* Objective-C: Same as in C. * Objective-C: Same as in C.

View File

@ -99,7 +99,7 @@ Windows
or even write new tests at all, PTVS is an indispensable debugging or even write new tests at all, PTVS is an indispensable debugging
extension to VS that enables full editing and debugging support for Python extension to VS that enables full editing and debugging support for Python
(including mixed native/managed debugging). (including mixed native/managed debugging).
* `SWIG for Windows <http://www.swig.org/download.html>_` * `SWIG for Windows <http://www.swig.org/download.html>`_
The steps outlined here describes how to set up your system and install the The steps outlined here describes how to set up your system and install the
required dependencies such that they can be found when needed during the build required dependencies such that they can be found when needed during the build

View File

@ -229,7 +229,7 @@ good testing practices.
time (e.g., C and C++) there is also usually no process necessary to test time (e.g., C and C++) there is also usually no process necessary to test
the `SBType`-related parts of the API. With those languages it's also the `SBType`-related parts of the API. With those languages it's also
possible to test `SBValue` by running expressions with possible to test `SBValue` by running expressions with
`SBTarget.EvaluateExpression` or the `expect_expr` testing utility. `SBTarget.EvaluateExpression` or the ``expect_expr`` testing utility.
Functionality that always requires a running process is everything that Functionality that always requires a running process is everything that
tests the `SBProcess`, `SBThread`, and `SBFrame` classes. The same is true tests the `SBProcess`, `SBThread`, and `SBFrame` classes. The same is true
@ -315,27 +315,27 @@ A better way to write the test above would be using LLDB's testing function
self.expect_expr("2 + 2", result_value="0") self.expect_expr("2 + 2", result_value="0")
**Prefer using specific asserts over the generic assertTrue/assertFalse.**. **Prefer using specific asserts over the generic assertTrue/assertFalse.**.
The `self.assertTrue`/`self.assertFalse` functions should always be your The ``self.assertTrue``/``self.assertFalse`` functions should always be your
last option as they give non-descriptive error messages. The test class has last option as they give non-descriptive error messages. The test class has
several expressive asserts such as `self.assertIn` that automatically several expressive asserts such as ``self.assertIn`` that automatically
generate an explanation how the received values differ from the expected generate an explanation how the received values differ from the expected
ones. Check the documentation of Python's `unittest` module to see what ones. Check the documentation of Python's ``unittest`` module to see what
asserts are available. LLDB also has a few custom asserts that are tailored asserts are available. LLDB also has a few custom asserts that are tailored
to our own data types. to our own data types.
+-----------------------------------------------+-----------------------------------------------------------------+ +-----------------------------------------------+-----------------------------------------------------------------+
| **Assert** | **Description** | | **Assert** | **Description** |
+-----------------------------------------------+-----------------------------------------------------------------+ +-----------------------------------------------+-----------------------------------------------------------------+
| ``assertSuccess`` | Assert that an ``lldb.SBError`` is in the "success" state. | | ``assertSuccess`` | Assert that an ``lldb.SBError`` is in the "success" state. |
+-----------------------------------------------+-----------------------------------------------------------------+ +-----------------------------------------------+-----------------------------------------------------------------+
| ``assertState`` | Assert that two states (``lldb.eState*``) are equal. | | ``assertState`` | Assert that two states (``lldb.eState*``) are equal. |
+-----------------------------------------------+-----------------------------------------------------------------+ +-----------------------------------------------+-----------------------------------------------------------------+
| ``assertStopReason`` | Assert that two stop reasons (``lldb.eStopReason*``) are equal. | | ``assertStopReason`` | Assert that two stop reasons (``lldb.eStopReason*``) are equal. |
+-----------------------------------------------+-----------------------------------------------------------------+ +-----------------------------------------------+-----------------------------------------------------------------+
If you can't find a specific assert that fits your needs and you fall back If you can't find a specific assert that fits your needs and you fall back
to a generic assert, make sure you put useful information into the assert's to a generic assert, make sure you put useful information into the assert's
`msg` argument that helps explain the failure. ``msg`` argument that helps explain the failure.
:: ::
@ -599,8 +599,6 @@ line to your ``~/.pdbrc``:
alias lldb self.dbg.HandleCommand("%*") alias lldb self.dbg.HandleCommand("%*")
::
Debugging Test Failures on Windows Debugging Test Failures on Windows
`````````````````````````````````` ``````````````````````````````````

View File

@ -39,8 +39,8 @@ decoder library [LibIPT library](https://github.com/intel/libipt).
$ cd libipt-build $ cd libipt-build
$ make $ make
This will generate a few files in the `<libipt-build>/lib` This will generate a few files in the ``<libipt-build>/lib``
and `<libipt-build>/libipt/include` directories. and ``<libipt-build>/libipt/include`` directories.
Configure and build LLDB with Intel PT support Configure and build LLDB with Intel PT support