Automated code diagrams of the graphviz codebase (and some browser engines) in searchfox

Hi, I’m a developer at Mozilla and just wanted to show off the latest experimental iteration of some automated diagramming functionality I’ve been working on for our source code indexing tool, searchfox which is entirely built on the amazing, stupendous, I couldn’t live without it, graphviz. I’ve added a graphviz tree (updates daily) to searchfox. Note that because the diagramming functionality is experimental and not yet accessible to screen-readers, it’s not surfaced in the UI by default; direct links to diagrams work, but to have context menus show diagramming options, it’s necessary to go to the searchfox [settings page] and set the “Default feature gate” or “Diagramming feature gate” to alpha.


The above is a screenshot of the live query calls-to:‘emit_html_txt’ depth:12 using the default namespace hierarchy.


This is a variation of the above query with hier:file used to specify that the paths of the files containing the relevant definitions should be used for hierarchy instead, becoming calls-to:‘emit_html_txt’ depth:12 hier:file.

Beyond calls-to, it’s also possible to find control flow paths between functions, like calls-between:‘agcontains’ calls-between:‘dot_layout’ depth:12 hier:file. It’s also possible to output the raw dot file that’s generated by specifying graph-format:raw-dot.

In code-bases like Firefox/Gecko, the use of C++ and namespaces can potentially make things more interesting for hierarchical clustering, for example, the query calls-between:‘MessagePort::PostMessage’ calls-between:‘PostMessageRunnable::DispatchMessage’ calls-between:‘MessagePort::MessagesReceived’ helps shows the IPC flow for a postMessage flowing between multiple processes. (The hier:flat variant is somewhat more straightforward but with less concept of the code organization.) And the significantly more experimental class-diagram:ServiceWorkerManager depth:4 tries to capture the relationship between various classes and data-structures.

Cribbing from a post to our dev-platform list about the update, other available options are:

  • hier:pretty - Default hierarchy based on pretty symbol name.
  • hier:flat - Oh no, I hate this hierarchy stuff! Please go back to the old way!
  • hier:subsystem - Namespaces are great, but I love bugzilla and wish the file mapping that tells us the bugzilla component for every file could be used instead.
  • hier:file - You know what? Forget bugzilla, I love the filesystem and want fine granularity file-level hierarchy.
  • hier:dir - That was too much granularity, just group by directories please.
  • graph-layout:dot - Default layout. It’s the best!
  • graph-layout:neato - That was too orderly, I want a diagram that stresses me out using a force-directed layout sorta thing.
  • graph-layout:fdp - That was good, but I’d like the edge lengths to be either much longer or much shorter, depending on random factors I have no control over.
  • depth:N - I would like to limit the graph’s traversal to this level of depth. Now 1-based!
  • node-limit:N - I saw a message about a limit being hit and I really want more stuff in my graph. Alternately, maybe I want less stuff in my graph but I want something less deterministic than limiting the depth.
  • path-limit:N - I saw a message about a node not being considered because it had too many edges, but I really want that node expanded so my graph can have a lot going on.
  • calls-between:foo calls-between:bar - I wish there was a way to intersect calls-to for multiple symbols to find the path between one or more things.
  • fmus-through-depth:0 - “field member uses” - If someone has a pointer to the class I’m asking for a diagram of, I want the in edges that come from that even though most of the time this is complicates the graph too much. By setting a value of 0, I only apply it to the depth 0 nodes in the diagram, preserving maximum sanity. I understand I can set the number higher at significant threat to the foundations of reality.

General caveats are that searchfox’s understanding of C++ comes from running the build process with a clang plugin and it’s likely not all bells and whistles are being compiled, so there may be files without semantic results. Searchfox tries to do a hybrid thing where it also combines fulltext search results for its default search, but the context menu searches are biased towards performing a semantic search only, although there is a “substring” search option. The setup and build scripts can potentially be augmented to maybe install some more packages in ubuntu and perhaps build some more things if desired.

Thanks to everyone involved in graphviz for creating and maintaining such an amazing and powerful tool!

6 Likes

Very nice! You can browse the ci/ directory in the Graphviz repository to see what’s being installed/configured when we build and test Graphviz.

1 Like