how to dump/trace the include path to a previous definition

Clang Frontend
#1

Hi there.

Is there a way to get clang to store/dump the include path to previous definitions/typedefs?

Saying that A, defined in file B, line C was previously defined in file B, line C isn't helpful.

I know, I know, "don't include the same header file twice" but I have good reasons to do so.

Details:

I have several projects that use header files to do the "C" equivalent of class template definitions.
The "templates" are things like AVL trees, and the "classes" are instantiations of the template with #defines standing in for template arguments.

This approach is currently the only way I can get multiple instances of the same template into a translation unit without name clashes - I wish there was a better way.

Unfortunately this approach isn't without its problems.

My next release will include the project files using "-I\${top_srcdir}" instead of "-isystem ${top_srcdir}" and this has uncovered problems now that the compiler knows the project include files are not system headers.

The one I'm stumped by is typedef redefinitions caused by multiple inclusion from the same include file.

I'm sure a solution to this problem would be of use to others too - I'm not the only one who uses tricks like this.

Regards,
Philip Ashmore

#2

Is there any special reason that you would use:

#include “mytrick.h”

Instead of a regular macro invitation with arguments:

MY_TRICK()

?

Clang would deal with the latter very nicely, especially since Chandler worked out the macro expansion in diagnostics.

– Matthieu

#3

Here are a few reasons off the top of my head:
1. Putting code inside a macro makes debugging almost impossible
2. some parts of the include file are conditional, surrounded with #if #endif
    I'll grant you that macro name munging so that the excluded code is in the "off"
    branch, but then we're back to (1)
3. I reported a bug about a problem with cpp's macro expansion -
    "cpp-4.4: incorrect macro expansion when a macro call results in the same macro being called"
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590008

I know I can do the clang -E trick to examine the preprocessed output, but since clang is
all about useful and descriptive diagnostics, I thought that a check that something being
redefined by the same file/line to prompt a backtrace of the previous definition would save
me and others from the trouble - yet another reason to use clang.

Philip