[PATCH] Fix makeFileCharRange for macro arguments in the presence of nested macro calls.

Manuel Klimek klimek at google.com
Mon May 13 00:23:22 PDT 2013


+Argyrios


On Wed, May 8, 2013 at 5:19 PM, Manuel Klimek <klimek at google.com> wrote:

> Hi doug.gregor,
>
> Added tests that show the problems:
> 1. isAt(Start|End)OfMacroExpansion did not work correctly for nested macro
>    calls; consider
>    #define M(x) x
>    #define N(x) x
>    N(f(M(i)))
>    Here getSourceText would return "M(f(M(i)))" for the token location of
> 'i',
>    as makeFileCharRange would consider 'i' to be at the start of the macro.
>    The problem is that getDecomposedLoc in this case returns the offset
> from
>    the inner call to 'M', and I have not found a way to get the offset from
>    'N' easily, as this information seems to be incrementally overwritten
> during
>    preprocessing.
>    The solution is to instead take the location before / after the examined
>    location and check whether its expansion location is the same as the
>    expansion location of the examined location. If this is the case, the
>    location before / after is not the first / last token of the macro
> expansion.
>
> 2. makeFileCharRange only considered the outermost layer of macro
> expansion,
>    thus not returning the widest possible range if the outermost expansion
>    was not fully describing the range.
>    After fixing (1), this would lead to getSourceText returning an empty
>    string instead of "M(i)".
>
> Note that I'm still not sure I'm entirely happy with this implementation.
> So far I have not found a good way to figure out whether the location
> is good to call getLocWithOffset(-1) or getLocWithOffset(tokLen + 1) on.
> Especially for the latter, the check for SM.isLocalSourceLocation(...)
> seems
> to work, but doesn't seem like the right solution. Any hints for a better
> solution would be highly welcome.
>
> http://llvm-reviews.chandlerc.com/D767
>
> Files:
>   lib/Lex/Lexer.cpp
>   unittests/Lex/LexerTest.cpp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130513/9b986e4e/attachment.html>


More information about the cfe-commits mailing list