Closed Bug 1760161 Opened 3 years ago Closed 3 years ago

Extend string pretty printing coverage & smartptr pretty printer

Categories

(Firefox Build System :: General, enhancement)

enhancement

Tracking

(firefox103 fixed)

RESOLVED FIXED
103 Branch
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.

Flags: needinfo?(mh+mozilla)

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.

Assignee: nobody → simon.farre.cx
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

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.

Current pretty printer output

Attached image new_pretty_printer.png

What suggest pretty printer output would produce in IDE's

This is how the standard library pretty printer for std::unique_ptr<T>'s look these days

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

Pushed by nalexander@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/baa4df264ef3 Enhance string & smartptr pretty printers. r=nalexander
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch
Flags: needinfo?(mh+mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: