Skip to content

Commit a93aa53

Browse files
committed
[lldb/Docs] Fix formatting for the variable formatting page
1 parent 64c4dcb commit a93aa53

File tree

1 file changed

+15
-14
lines changed

1 file changed

+15
-14
lines changed

lldb/docs/use/variable.rst

Lines changed: 15 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -366,12 +366,13 @@ simply say ${var.z} because that symbol refers to the pointer z. In order to
366366
dereference it and get the pointed value, you should say ``${*var.z}``. The
367367
``${*var`` tells LLDB to get the object that the expression paths leads to, and
368368
then dereference it. In this example is it equivalent to ``*(bObject.z)`` in
369-
C/C++ syntax. Because . and -> operators can both be used, there is no need to
370-
have dereferences in the middle of an expression path (e.g. you do not need to
371-
type ``${*(var.x).x}``) to read A::x as contained in ``*(B::x)``. To achieve
372-
that effect you can simply write ``${var.x->x}``, or even ``${var.x.x}``. The
373-
``*`` operator only binds to the result of the whole expression path, rather
374-
than piecewise, and there is no way to use parentheses to change that behavior.
369+
C/C++ syntax. Because ``.`` and ``->`` operators can both be used, there is no
370+
need to have dereferences in the middle of an expression path (e.g. you do not
371+
need to type ``${*(var.x).x}``) to read A::x as contained in ``*(B::x)``. To
372+
achieve that effect you can simply write ``${var.x->x}``, or even
373+
``${var.x.x}``. The ``*`` operator only binds to the result of the whole
374+
expression path, rather than piecewise, and there is no way to use parentheses
375+
to change that behavior.
375376

376377
Of course, a summary string can contain more than one ${var specifier, and can
377378
use ``${var`` and ``${*var`` specifiers together.
@@ -573,7 +574,7 @@ the pointer value. However, because pointers have no notion of their size, the
573574
empty brackets [] operator does not work, and you must explicitly provide
574575
higher and lower bounds.
575576

576-
In general, LLDB needs the square brackets operator [] in order to handle
577+
In general, LLDB needs the square brackets ``operator []`` in order to handle
577578
arrays and pointers correctly, and for pointers it also needs a range. However,
578579
a few special cases are defined to make your life easier:
579580

@@ -882,9 +883,9 @@ As a shortcut for this, you can inherit from lldb.SBSyntheticValueProvider, and
882883
just define get_value as other methods are defaulted in the superclass as
883884
returning default no-children responses.
884885

885-
If a synthetic child provider supplies a special child named $$dereference$$
886-
then it will be used when evaluating opertaor* and operator-> in the frame
887-
variable command and related SB API functions.
886+
If a synthetic child provider supplies a special child named
887+
``$$dereference$$`` then it will be used when evaluating ``operator *`` and
888+
``operator ->`` in the frame variable command and related SB API functions.
888889

889890
For examples of how synthetic children are created, you are encouraged to look
890891
at examples/synthetic in the LLDB trunk. Please, be aware that the code in
@@ -960,10 +961,10 @@ expression:
960961
Error [IRForTarget]: Call to a function '_ZNSt33vector<int, std::allocator<int> >ixEm' that is not present in the target
961962
error: Couldn't convert the expression to DWARF
962963

963-
The reason for this is that classes might have an overloaded operator [], or
964-
other special provisions and the expression command chooses to ignore synthetic
965-
children in the interest of equivalency with code you asked to have compiled
966-
from source.
964+
The reason for this is that classes might have an overloaded ``operator []``,
965+
or other special provisions and the expression command chooses to ignore
966+
synthetic children in the interest of equivalency with code you asked to have
967+
compiled from source.
967968

968969
Filters
969970
-------

0 commit comments

Comments
 (0)