http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #6 from dodji at seketeli dot org <dodji at seketeli dot org>
2012-11-19 16:17:20 UTC ---
> I think this his how the macro expansion was designed to work: It
> shows the location of the token that triggered the error.
Yes. And there are cases where the GCC way seems to make more sense;
for instance:
$ cat -n test.c
1 #define OPERATE(OPRD1, OPRT, OPRD2) \
2 OPRD1 OPRT OPRD2;
3
4 #define SHIFTL(A,B) \
5 OPERATE (A,<<,B)
6
7 #define MULT(A) \
8 SHIFTL (A,1)
9
10 void
11 g ()
12 {
13 MULT (1.0);// 1.0 << 1; <-- so this is an error.
14 }
$
With GCC:
./test.c: In function ‘g’:
./test.c:5:14: error: invalid operands to binary << (have ‘double’ and ‘int’)
OPERATE (A,<<,B)
^
./test.c:2:9: note: in definition of macro ‘OPERATE’
OPRD1 OPRT OPRD2;
^
./test.c:8:3: note: in expansion of macro ‘SHIFTL’
SHIFTL (A,1)
^
./test.c:13:3: note: in expansion of macro ‘MULT’
MULT (1.0);// 1.0 << 1; <-- so this is an error.
^
$
With Clang:
test.c:13:3: error: invalid operands to binary expression ('double' and 'int')
MULT (1.0);// 1.0 << 1; <-- so this is an error.
^~~~~~~~~~
test.c:8:3: note: expanded from macro 'MULT'
SHIFTL (A,1)
^
test.c:5:14: note: expanded from macro 'SHIFTL'
OPERATE (A,<<,B)
^
test.c:2:9: note: expanded from macro 'OPERATE'
OPRD1 OPRT OPRD2;
~~~~~ ^ ~~~~~
1 error generated.
$
So, at line 13.3, I think it doesn't make sense to talk about a binary
expression (which is related to the '<<' operator).
So yes, we chose to first point to the token on which the error
appeared, and then print the context of the macro expansion all the way
to the expansion point.
Now I am not sure what the best approach should be.
> I also agree that the clang way makes more sense in this case.
Indeed.
