[cfe-dev] Viewing clang ASTs

Joshua Cranmer Pidgeot18 at gmail.com
Fri Jul 22 17:19:49 PDT 2011


In my ongoing attempt to use clang as a source of information to build 
DXR output, I have often found that the online documentation for most of 
the stuff, well, sucks. The biggest pain point is that the doxygen just 
completely fails to figure out what I can visit using 
RecursiveASTVisitor, and, on top of it, manages to not think that 
DeclCXX.h contains anything documentable. I've gotten around these bugs 
by hosting an index of clang on DXR (<http://dxr.mozilla.org/clang/>), 
but that still leaves me in the lurch if I'm trying to understand why 
one line mysteriously fails to produce the correct output even when the 
previous line is correct.

My solution for this was to put a simple web frontend around a tool 
which just dumps the TranslationUnit in a JSON-ish format. For lack of 
better naming, I've called it "viewsource", and you can find a version 
at <http://dxr.mozilla.org/viewsource/>. The source code is located on 
github at <https://github.com/jcranmer/viewsource/> if you want to look 
at it. It's nowhere near complete--I've only managed to dump out Decl 
statements as well as TypeLoc (though that's not in the online version 
yet), although I hope to handle Types, Stmts, and Exprs before long. The 
tool works by building up the information into something akin to a JS 
object tree internally and then dumps it out, with hooks to handle 
cycles a bit more gracefully than infinitely looping; with some tweaks, 
this same basic format could probably be used to build bindings for 
$DYNAMIC_LANGUAGE to allow people to write compiler plugins in languages 
other than C++.

I apologize for the crappy UI, but polishing web UI is a low priority 
for me right now. Incidentally, the tool also has support for displaying 
equivalent Dehydra information for gcc as well as dumping the parse tree 
(according to Mozilla's implementation) for JavaScript source code.

Incidentally, I'd also like to ask if there is the potential for an 
easier way to represent AST node metadata than reading off all of the 
method names and hoping that everyone uses the same naming convention (I 
have to special case a few people who don't follow the same convention).

-- 
Joshua Cranmer
News submodule owner
DXR coauthor




More information about the cfe-dev mailing list