[llvm-bugs] [Bug 26247] New: Nested macros producing different locations due to whitespace changes

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26247

            Bug ID: 26247
           Summary: Nested macros producing different locations due to
                    whitespace changes
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rtrieu at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 15686
  --> https://llvm.org/bugs/attachment.cgi?id=15686&action=edit
Test Case

I was attempting to track down an issue with a warning and nesting macros,
specifically the NULL macro.  That was when I discovered the warning behavior
was dependent on the whitespace inside one of the macro definitions.  In the
attached test case, a warning is generated for "assert(test1());" while no
warning is emitted for "assert(test2());"  However, the definition of test1 and
test2 only differ by two spaces.

The warning logic is in SemaChecking.cpp:7045 in the DiagnoseNullConversion
function.  The difference is that one will have the MacroName of "NULL" while
the one does not.  The warning depends on finding the NULL macro name to
perform the analysis properly.

>From the lexing side, one location difference was found in TokenLexer.cpp:796
inside updateConsecutiveMacroArgTokens.  The extra whitespace pushes one of the
macros over the relative offset limit of 50, splitting the macro tokens among
different SLoc's.  Remove the condition of "RelOffs > 50" appears to fix the
SourceLocation issue, but I'm not sure what else with macro handling that
condition affects.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160122/af1edc2e/attachment.html>