http://llvm.org/bugs/show_bug.cgi?id=9279
Summary: Macro expansion stack trace seriously broken with
function-style macros
Product: clang
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Pretty simple examples like:
% cat t.cc
#define M1(x) int arr[x]
#define M2(x) M1(x)
#define M3(x) M2(x)
M3(-1);
Lead to horrible diagnostics like:
% ./bin/clang++ -fsyntax-only t.cc
t.cc:5:1: error: 'arr' declared as an array with a negative size
M3(-1);
^~~~~~
t.cc:3:15: note: instantiated from:
#define M3(x) M2(x)
^
t.cc:2:15: note: instantiated from:
#define M2(x) M1(x)
^
t.cc:5:1: note: instantiated from:
M3(-1);
^ ~~
t.cc:3:15: note: instantiated from:
#define M3(x) M2(x)
^
t.cc:5:1: note: instantiated from:
M3(-1);
^ ~~
t.cc:5:4: note: instantiated from:
M3(-1);
^~
1 error generated.
Whereas plain macros yield a much nicer diagnostic:
% cat t2.cc
#define M1 int arr[-
#define M2 M1
#define M3 M2
M3 1];
% ./bin/clang++ -fsyntax-only t2.cc
t2.cc:5:1: error: 'arr' declared as an array with a negative size
M3 1];
^~~~
t2.cc:3:12: note: instantiated from:
#define M3 M2
~~~~~~~~~~~^~
t2.cc:2:12: note: instantiated from:
#define M2 M1
~~~~~~~~~~~^~
t2.cc:1:20: note: instantiated from:
#define M1 int arr[-
^
1 error generated.
There are a couple of distinct symptoms here, but likely they stem from the
same core issue:
- We generate a stack for each note in the original stack, making the total
diagnostic far longer than necessary.
- We don't ever show the bottom of the stack
- The source ranges for the secondary stacks are superior to those of the
initial stack
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
