[cfe-dev] Decl::dumpXML and -DNDEBUG

[Alexander Kornienko]

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.


On Tue, Jul 17, 2012 at 6:40 PM, Matthieu Monrocq <
matthieu.monrocq at gmail.com> wrote:

>
>
> On Mon, Jul 16, 2012 at 7:44 PM, Alexander Kornienko <alexfh at google.com>wrote:
>
>> 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
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
> 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
>



-- 
Alexander Kornienko | Software Engineer | alexfh at google.com | +49 151 221
77 957
Google Germany GmbH | Dienerstr. 12 | 80331 München
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120717/349c1481/attachment.html>