This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/24985] caret diagnostics



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]