[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