Extend string pretty printing coverage & smartptr pretty printer
Categories
(Firefox Build System :: General, enhancement)
Tracking
(firefox103 fixed)
Tracking | Status | |
---|---|---|
firefox103 | --- | fixed |
People
(Reporter: simon.farre.x, Assigned: simon.farre.x)
Details
Attachments
(4 files)
Currently the string pretty printer do not cover most strings and I'm creating this issue for a bug number to submit a patch for, where additional string types are added.
The smartptr pretty printer also is served well to have a children()
method, because this returns a (string, gdb.Value)
- which means that IDE's can use the value produced by the pretty printer to display additional information (if they support or work with the Python integration in GDB). This is currently not possible due to it only having a to_string()
method which just returns a string. From the command line, the output result is almost identical or can be made to look almost identical if that's desirable.
The GDB docs states that, if both to_string
and children
exists, the to_string
result will be prepended to the children
output on the command line, so there could be case to be made to remove to_string
entirely and use children only.
Assignee | ||
Comment 1•3 years ago
|
||
Added two additional string types to be pretty printed by the string
pretty printer.
Added the children method to smartpr, which yields 1 child. Has
the added benefit of returning (name, gdb.Value) which can be used
from an IDE with support for Python in GDB.
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
So the output differences on the smartptr pretty printing output are these;
Old:
$1 = [(nsDocShell *) 0x7f8f81c741a0]
New:
$1 = [(nsDocShell *)] = {mRawPtr = 0x7f8f81c741a0}
The right hand side of the first =
is the output from the children
method and can be changed. Removing to_string
would mean the output would look like this, instead
$1 = {mRawPtr = 0x7f8f81c741a0}
Adding the previous type information (of the pointer) could be placed where mRawPtr
is, if that's desirable.
Either way, this also has the added benefit of being able to use the value produced by the pretty printer in Python.
Assignee | ||
Comment 3•3 years ago
|
||
Current pretty printer output
Assignee | ||
Comment 4•3 years ago
|
||
What suggest pretty printer output would produce in IDE's
Assignee | ||
Comment 5•3 years ago
|
||
This is how the standard library pretty printer for std::unique_ptr<T>
's look these days
Assignee | ||
Comment 6•3 years ago
|
||
I've added screenshots for how these pretty printers differ and I've also added the standard library's own pretty printer for reference, to show examples of what it should resemble to produce good outputs, for IDE's or editors
https://hg.mozilla.org/mozilla-central/rev/baa4df264ef3
https://hg.mozilla.org/mozilla-central/rev/3eda75ec5800
Updated•2 years ago
|
Description
•