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

[Michael137]

Summary

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

lldb/bindings/interface/SBModule.i

public:
     bool
     IsValid () const;
 
     explicit operator bool() const;
 
     void
     Clear();
 
-    %feature("docstring", "Check if the module is file backed.
+    %feature("docstring", "
+    Check if the module is file backed.
+
     @return
+
         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;
     bool
     IsFileBacked() const;
 
     %feature("docstring", "
     Get const accessor for the module file specification.
 

lldb/bindings/interface/SBTarget.i

#endif
     GetDescription (lldb::SBStream &description, lldb::DescriptionLevel description_level);
 
     lldb::addr_t
     GetStackRedZoneSize();
 
     %feature("docstring", "
     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
-    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
     ") IsLoaded;
     bool
     IsLoaded (const lldb::SBModule &module) const;
 
     lldb::SBLaunchInfo
     GetLaunchInfo () const;

lldb/bindings/interface/SBType.i

public:
 
     Language-specific behaviour:
 
     * C: The output is expected to match the value of ``sizeof(Type)``. If
       ``sizeof(Type)`` is not a valid expression for the given type, the
       function returns ``0``.
     * C++: Same as in C.
     * 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;
     uint64_t
     GetByteSize();
 
 
     %feature("docstring",
     "Returns true if this type is a pointer type.
 
public:
     lldb::SBType
     GetArrayElementType ();
 
     %feature("docstring",
     "Returns the array type with the given constant size.
 
     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.
     * Objective-C: Same as in C.
 
     See also `IsArrayType` and `GetArrayElementType`.
     ") GetArrayType;
     lldb::SBType
     GetArrayType (uint64_t size);
 

lldb/docs/resources/build.rst

* `Python 3 <https://www.python.org/downloads/windows/>`_.  Make sure to (1) get
   the x64 variant if that's what you're targetting and (2) install the debug
   library if you want to build a debug lldb. The standalone installer is the
   easiest way to get the debug library.
 * `Python Tools for Visual Studio
   <https://github.com/Microsoft/PTVS/>`_. If you plan to debug test failures
   or even write new tests at all, PTVS is an indispensable debugging
   extension to VS that enables full editing and debugging support for Python
   (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
 required dependencies such that they can be found when needed during the build
 process. They only need to be performed once.
 
 #. Install Visual Studio with the "Desktop Development with C++" workload and
    the "Python Development" workload.
 #. Install GnuWin32, making sure ``<GnuWin32 install dir>\bin`` is added to

lldb/docs/resources/test.rst

**Don't unnecessarily launch the test executable.**
     The part of the SB API that can be tested with just a target includes
     everything that represents information about the executable and its
     debug information (e.g., `SBTarget`, `SBModule`, `SBSymbolContext`,
     `SBFunction`, `SBInstruction`, `SBCompileUnit`, etc.). For test executables
     written in languages with a type system that is mostly defined at compile
     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
     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
     tests the `SBProcess`, `SBThread`, and `SBFrame` classes. The same is true
     for tests that exercise breakpoints, watchpoints and sanitizers.
     Languages such as Objective-C that have a dependency on a runtime
     environment also always require a running process.
 
 **Don't unnecessarily include system headers in test sources.**

 A better way to write the test above would be using LLDB's testing function
 ``expect_expr`` will only pass if the expression produces a value of 0:
 
 ::
 
     self.expect_expr("2 + 2", result_value="0")
 
 **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
-    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
-    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
     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. |
 +-----------------------------------------------+-----------------------------------------------------------------+
 
     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
-    `msg` argument that helps explain the failure.
+    ``msg`` argument that helps explain the failure.
 
 ::
 
     # Bad. Will print a generic error such as 'False is not True'.
     self.assertTrue(expected_string in list_of_results)
     # Good. Will print expected_string and the contents of list_of_results.
     self.assertIn(expected_string, list_of_results)
 

 addition to pdb's debugging facilities, lldb commands can be executed with the
 help of a pdb alias. For example ``lldb bt`` and ``lldb v some_var``. Add this
 line to your ``~/.pdbrc``:
 
 ::
 
    alias lldb self.dbg.HandleCommand("%*")
 
-::
-
 Debugging Test Failures on Windows
 ``````````````````````````````````
 
 On Windows, it is strongly recommended to use Python Tools for Visual Studio
 for debugging test failures. It can seamlessly step between native and managed
 code, which is very helpful when you need to step through the test itself, and
 then into the LLDB code that backs the operations the test is performing.
 

lldb/docs/use/intel_pt.rst

 ::
 
   $ git clone [e-mail]:intel/libipt.git
   $ mkdir libipt-build
   $ cmake -S libipt -B libipt-build
   $ cd libipt-build
   $ make
 
-This will generate a few files in the `<libipt-build>/lib`
-and `<libipt-build>/libipt/include` directories.
+This will generate a few files in the ``<libipt-build>/lib``
+and ``<libipt-build>/libipt/include`` directories.
 
 Configure and build LLDB with Intel PT support
 
 ::
 
   $ cmake \
       -DLLDB_BUILD_INTEL_PT=ON \
       -DLIBIPT_INCLUDE_PATH="<libipt-build>/libipt/include" \