[Bug c++/45333] Include macros in instantiation backtraces

dodji at seketeli dot org gcc-bugzilla@gcc.gnu.org
Thu Oct 20 08:26:00 GMT 2011


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.



More information about the Gcc-bugs mailing list