[cfe-dev] Clang, macros and declarations

[Eli Friedman]

On Wed, Aug 14, 2013 at 8:36 AM, George Kastrinis <
george.kastrinis at logicblox.com> wrote:

> Thanks. Yeah, SourceManager::getImmediateMacroCallerLoc is what we though
> might help to get all the expansion stack and I think it helped in some
> cases. But now we have the following issue (again from the same math
> header!). Say you have in file a.cpp
>
> #define __THROW throw ()
>
> #define __MATHCALL(function, args) \
>   __MATHDECL (double,function, args)
> #define __MATHDECL(type, function, args) \
>   __MATHDECL_1(type, function, args); \
>   __MATHDECL_1(type, __ ## function, args)
> #define __MATHDECL_1(type, function, args) \
>   extern type __MATH_PRECNAME(function) args __THROW
>
> #define __MATH_PRECNAME(name) name
> #include "b.h"
> #undef __MATH_PRECNAME
>
> #define __MATH_PRECNAME(name) name##f
> #include "b.h"
> #undef __MATH_PRECNAME
>
> and in b.h
>
> __MATHCALL (cpow, (double __x, double __y));
>
> This will create 4 functions (cpow, __cpow, cpowf, __cpowf).
> Using SourceManager::getImmediateMacroCallerLoc we are able to
> differentiate for example cpow and __cpow. But there is still an issue with
> cpow and cpowf (and with __cpow and __cpowf). Those pairs have the same
> locations even when getting the whole expansion macro.
>
> Is there anything we can do to handle this case?
>
>
>
I think you also need to track the include stack.
SourceManager::getDecomposedIncludedLoc might be useful here.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130814/2a0c0bd8/attachment.html>