------- Comment #6 from manu at gcc dot gnu dot org 2009-07-03 00:25 ------- (In reply to comment #5) > Manuel, pardon the naive question: are we getting closer to fixing this? I'm > asking because I saw patches about column numbers and wondered if that really > means that very soon we'll be able to just print a caret instead ;)
Not really, if we ever have caret diagnostics, then it will be more accurate, but it does not get us closer to print a source line. Of course, anything is better than nothing and accurate column numbers are probably useful even without caret diagnostics. The fundamental thing missing is a location_t-> const char * (source line) translator. Quoting from http://gcc.gnu.org/wiki/Better_Diagnostics 3) A location(s) -> source strings interface and machinery. Ideally, this should be more or less independent of CPP, so CPP (through the diagnostics machinery) calls into this when needed and not the other way around. This can be implemented in several ways: a) Keeping the CPP buffers in memory and having in line-maps pointers directly into the buffers contents. This is easy and fast but potentially memory consuming. Care to handle charsets, tabs, etc must be taken into account. Factoring out anything useful from libcpp would help to implement this. b) Re-open the file and fseek. This is not trivial since we need to do it fast but still do all character conversions that we did when libcpp opened it the first time. This is approximately what Clang (LLVM) does and it seems they can do it very fast by keeping a cache of buffers ever reopened. I think that thanks to our line-maps implementation, we can do the seeking quite more efficiently in terms of computation time. However, opening files is quite embedded into CPP, so that would need to be factored out so we can avoid any unnecessary CPP stuff when reopening but still do it *properly* and *efficiently*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
