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

Argyrios Kyrtzidis akyrtzi at gmail.com
Tue May 14 10:17:03 PDT 2013


Hi Manuel,

The tests are great, give me some time and I'll investigate and comment on your patch soon(ish).

On May 13, 2013, at 12:23 AM, Manuel Klimek <klimek at google.com> wrote:

> +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/20130514/4d51bda0/attachment.html>


More information about the cfe-commits mailing list