libg++-2.8.1.3 and gcc-20000220 CVS

Gabriel Dos Reis gdr@codesourcery.com
Mon Feb 21 15:49:00 GMT 2000


Zack Weinberg <zack@wolery.cumb.org> writes:

[...]

| > <vector>: In instantiation of `iterator_traits<X>':
| > <vector>:   instantiated from `vector<_Tp>::_M_initialize_aux(_InputIterator, _InputIterator, __false_type) [with _InputIterator = X, _Tp = int]
| > 
| > [...]
| > 
| > <vector>:  no matching function for call to `__iterator_category (X &)'
| 
| I like the idea.  You could kludge this right now by tweaking my
| previous suggestion a bit, but it'd break debug info even more.  cc1
| would see something like
| 
| # 1 "<vector>" 1 3
| 
| ...
| 
| and no information about files included after that.
| 
| Also, it's worth considering what we do if we hit an error in a system
| header.  Fall back to the old method?

Actually it would be handful if there were a hook for each _DECL
pointing to a list of #included filenames.  Then we might define a
concept of "abstract header":

   a header is abstract if it is a system header (or deemed so via a
   #pragma) or #included by an abstract header.

In normal state we'd output the "primary" abstract header for
diagnotic purpose and make the debugger know about the full pathname
for its needs.  IMHO, that will solve the two problems: how 
to make diagnostics readable and keep the debugger happy.

As to how to revert to the old behaviour, a flag will tell us whether
we should systematically output absolute pathnames (which is just a
list-dump op)

cpp would be responsible for providing the header-list.

Does it sound feasable to you? 

-- Gaby


More information about the Gcc-bugs mailing list