@@ -366,12 +366,13 @@ simply say ${var.z} because that symbol refers to the pointer z. In order to
366
366
dereference it and get the pointed value, you should say ``${*var.z} ``. The
367
367
``${*var `` tells LLDB to get the object that the expression paths leads to, and
368
368
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.
375
376
376
377
Of course, a summary string can contain more than one ${var specifier, and can
377
378
use ``${var `` and ``${*var `` specifiers together.
@@ -573,7 +574,7 @@ the pointer value. However, because pointers have no notion of their size, the
573
574
empty brackets [] operator does not work, and you must explicitly provide
574
575
higher and lower bounds.
575
576
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
577
578
arrays and pointers correctly, and for pointers it also needs a range. However,
578
579
a few special cases are defined to make your life easier:
579
580
@@ -882,9 +883,9 @@ As a shortcut for this, you can inherit from lldb.SBSyntheticValueProvider, and
882
883
just define get_value as other methods are defaulted in the superclass as
883
884
returning default no-children responses.
884
885
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.
888
889
889
890
For examples of how synthetic children are created, you are encouraged to look
890
891
at examples/synthetic in the LLDB trunk. Please, be aware that the code in
@@ -960,10 +961,10 @@ expression:
960
961
Error [IRForTarget]: Call to a function '_ZNSt33vector<int, std::allocator<int> >ixEm' that is not present in the target
961
962
error: Couldn't convert the expression to DWARF
962
963
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.
967
968
968
969
Filters
969
970
-------
0 commit comments