Decl::dumpXML and -DNDEBUG

Hi all,

I’ve recently implemented a tool named clang-ast-dump, which allows to dump selectively an AST of user-specified translation units. It’s a really simple tool now, most of it’s code is node filtering. The rest is done by Decl::dumpXML.

Now the problem: Decl::dumpXML does nothing when compiled with -DNDEBUG. I assume that initially this method was meant to be only helpful during debugging of clang code, but now there are a couple of reasons to review this decision, I think:

  • clang -cc1 mode has a command line option “-ast-dump-xml”, which uses dumpXML, and currently it won’t work with -DNDEBUG (e.g. when builing with CMake: Release configuration + LLVM_ASSERTIONS_ENABLED=OFF);
  • clang-ast-dump tool uses it.

A comment in DumpXML.cpp states:
// Only pay for this in code size in assertions-enabled builds.

But having -ast-dump-xml option conflicts with this idea: either we have to disable this option completely in non-assertion-enabled builds, or we have to drop this idea of not-having the dumpXML implementation in them. The third option would be to drop the -ast-dump-xml option completely and instead use clang-ast-dump tool when needed. In this case we could only use an implementation of Decl::dumpXML in the tool and exclude it from clang binary.

–Regards,
Alexander Kornienko

I think the latter solution (separate tool) would perhaps make the most sense. It seems to me that we get the best of both worlds: a lean compiler and a verbose (and possibly richer and richer) tool for debugging.

If the tool had been maintained on a separate repository, the question of bitrot would have risen, however if we speak about a tool maintained within the clang repository (albeit a dedicated directory) then we can have the build bots verifying that it compiles and its test-suite pass so that modifications on the AST are propagated.

– Matthieu

Douglas,

What do you think about moving AST dumping from clang -cc1 to a separate tool (but leaving implementation inside clang libraries, so it can be used for debugging the compiler code)? As this functionality is still interesting to many developers (and I’d say that this interest increases), more features can be implemented inside the tool, which would never be implemented inside a compiler. This way we could remove dependencies on assertions and keep the compiler free from functions useful only while debugging AST-related code.

Douglas,

What do you think about moving AST dumping from clang -cc1 to a separate tool (but leaving implementation inside clang libraries, so it can be used for debugging the compiler code)? As this functionality is still interesting to many developers (and I’d say that this interest increases), more features can be implemented inside the tool, which would never be implemented inside a compiler. This way we could remove dependencies on assertions and keep the compiler free from functions useful only while debugging AST-related code.

Please see my recent reply to Manuel. I think making it a separate tool is the wrong way to go. It’s a debugging aid, and while it’s nice to expose it through -cc1/-Xclang to help with debugging form the command line (tweaks there would be nice), it’s also important to be able to call it from a debugger.

  • Doug