http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333
--- Comment #2 from dodji at seketeli dot org <dodji at seketeli dot org>
2011-10-20 08:25:20 UTC ---
Yes, it's related. With the infrastructure that is in right now, the
results are not super for template instantiate backtraces though:
$ cat -n test.cc
1 #define ZERO(c) c.set(0)
2
3 struct S
4 {
5 int a;
6 int b;
7 };
8
9 template <class T>
10 class C
11 {
12 T t;
13
14 public:
15 void set(int x) { t = x; }
16 };
17
18 void foo(C<S> &c)
19 {
20 ZERO(c);
21 }
22
23
24
$
When cc1plus -quiet -ftrack-macro-expansion ./test.cc yields:
test.cc: In instantiation of ‘void C<T>::set(int) [with T = S]’:
test.cc:1:24: required from here
test.cc:15:21: erreur: no match for ‘operator=’ in ‘((C<S>*)this)->C<S>::t = x’
test.cc:15:21: note: candidate is:
test.cc:3:8: note: S& S::operator=(const S&)
test.cc:3:8: note: no known conversion for argument 1 from ‘int’ to ‘const
S&’
So it points to the spelling location (1:24) of the token involved in
the error message, rather than to the expansion point of the macro. I'd
like it to mention both, like it does for the C FE.
Beside fixing the various bootstrap breakages I have introduced, I'll
need to go through the template instantiation error message mechanics to
teach them how to use the new macro token tracking infrastructure, I
guess. :-)
At least we have the infrastructure now.
Thank you for the head-up.
