[LLVMbugs] [Bug 18485] New: Empty macro expansion from inside another macro causes incorrect placement of expanded macro

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Jan 15 04:52:01 PST 2014


http://llvm.org/bugs/show_bug.cgi?id=18485

            Bug ID: 18485
           Summary: Empty macro expansion from inside another macro causes
                    incorrect placement of expanded macro
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: eremeev at viva64.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Empty macro expansion from inside another macro causes incorrect placement of
expanded macro.
Consider the example:

#define B

#define A(type) B unsigned type
/*
empty lines
...
...
...
...*/
A(int) foo()
{}

The clang preprocessor (-E option) will output the following:

#line 1 "D:/home/paul/sample.c"
#line 1 "<built-in>"
#line 1 "<built-in>"
#line 156 "<built-in>"
#line 1 "<command line>"
#line 1 "<built-in>"
#line 1 "D:/home/paul/sample.c" unsigned int
#line 10 "D:/home/paul/sample.c"
       foo()
{}

Take a note, that the return type of the foo function is placed before #line
10, meaning that it is placed before the whitespace, thus incorrectly pointing
the start position of the foo to line 1 instead of line 10.

-- 
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/20140115/2e7595fc/attachment.html>


More information about the llvm-bugs mailing list