[cfe-dev] how to dump/trace the include path to a previous definition

[Philip Ashmore]

On 25/11/11 18:43, Matthieu Monrocq wrote:
>
>
> Le 25 novembre 2011 04:16, Philip Ashmore <contact at philipashmore.com 
> <mailto:contact at philipashmore.com>>
> a écrit :
>
>     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
>
>
> 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
>
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